perm filename COMSCH.MSG[SCH,LSP]33 blob
sn#876991 filedate 1989-09-11 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002
C00003 ENDMK
C⊗;
∂17-Jun-89 2139 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #139
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jun 89 21:39:33 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00495;
18 Jun 89 0:30 EDT
Date: 18 JUN 89 00:04:06 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #139
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8906180030.aa00495@mintaka.lcs.mit.edu>
Scheme Digest #139 18 JUN 89 00:04:06 EDT
Today's Topics:
BUG IN EXPANDED MEMORY TI PC-SCHEME?
----------------------------------------------------------------------
Date: 16 Jun 89 21:43:25 GMT
From: Brian Leverich <leverich@RAND.ORG>
Subject: BUG IN EXPANDED MEMORY TI PC-SCHEME?
Message-Id: <2102@randvax.UUCP>
On "long" simulation runs (20+ minutes on a 12mHz 286 with LIM 4.0 EMS...)
using PCSEXP, the _expanded memory_ version of Texas Instrument's
PC-Scheme, I apparently run low on space, the gc starts thrashing around,
and finally I get a Scheme reset because the system is out of space.
Problem is, I can't find anywhere near enough current structures to
fill memory. Moreover, (freesp) returns 400K + of memory, then if I
invoke (freesp) again (or anything else...) it triggers another gc
and sometimes another Scheme reset. I don't have the problem when I
use PCSEXT and jumper my expanded memory to act like extended. Looks
like (freesp) can see a big chunk of free space, but the gc isn't
adding it to the free list.
Anyone else had this problem with PCSEXP? Anyone have any workaround
suggestions? Tnx. -B
--
"Simulate it in ROSS"
Brian Leverich | U.S. Snail: 1700 Main St.
ARPAnet: leverich@rand.org | Santa Monica, CA 90406
UUCP: decvax!randvax!leverich | Ma Bell: (213) 393-0411 X7769
------------------------------
End of Scheme Digest
********************
∂18-Jun-89 2215 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #140
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 18 Jun 89 22:15:10 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22536;
19 Jun 89 1:05 EDT
Date: 19 JUN 89 00:06:11 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #140
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8906190105.aa22536@mintaka.lcs.mit.edu>
Scheme Digest #140 19 JUN 89 00:06:11 EDT
Today's Topics:
"unspecified" and SET!
----------------------------------------------------------------------
Date: 18 Jun 89 23:17:50 GMT
From: Dorai Sitaram <titan!dorai@rice.edu>
Subject: "unspecified" and SET!
Message-Id: <3902@kalliope.rice.edu>
The recent discussion of "unspecified" values reveals that Scheme is
not as syntactically uniform as it is claimed to be. Some Scheme
syntactic forms return meaningful values, others don't: the former are
"expressions" and the latter "commands". "Commands" are usually used
to represent side-effects, e.g., assignment in the form of set!. In
an expression-oriented language, a "command" is awkwardly "expressed"
by an expression returning an arbitrary "unspecified" value.
Perhaps, SET! is not the ideal side-effecting construct for an
expression-oriented language. Felleisen and Friedman [1] propose a
side-effecting construct called a SIGMA-capability. This looks just
like a LAMBDA-expression, but whereas LAMBDA introduces new bound
variables, SIGMA modifies the binding of existing lexical variables.
In other words, on applying a SIGMA-capability to arguments, the
variables corresponding to the SIGMA-parameters are side-effected.
Problems about "unspecified" return values disappear. The application
of a SIGMA-capability side-effects the SIGMA-parameters and returns
the result of evaluating the SIGMA-body (the parallel being the
application of a LAMBDA-expression). In addition, SIGMA gives a very
natural method for parallel assignment, since the arguments to a
SIGMA-capability are all evaluated before the application performs the
side-effects.
We can retrieve the old SET! from SIGMA as follows:
(set! x a) == ((sigma (x) <what-now>) a)
where <what-now> is the "unspecified" value of your choice. Thus,
there is no dependence on a system-chosen unspecified value.
Even better, we need not fall back on a command with its necessarily
arbitrary choice of unspecified return value. We can define a
_generalized_ SET! in terms of SIGMA that is more along the lines of
LET in terms of LAMBDA:
(set! ([x a] ...) e ...) == ((sigma (x ...) e ...) a ...)
The upshot of all this is that while we have side-effects, we still
have a syntactically uniform language.
--dorai
[1] Felleisen & Friedman, A calculus for assigments ..., POPL 1987,
314 - 325.
ps: In terms of SET!, SIGMA's effect is as follows:
(sigma (x ...) e ...) == (lambda (x↑ ...) (set! x x↑) ... e ...)
where x↑ ... are new variables, used only to show what's going on. A
native implementation of SIGMA is simply got by mimicking LAMBDA,
except for the following: where LAMBDA has extend-environment, SIGMA
has update-environment.
-------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
-------------------------------------------------------------------------------
------------------------------
End of Scheme Digest
********************
∂19-Jun-89 1414 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu another change for R4RS; peek-char
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 19 Jun 89 14:14:15 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04503;
19 Jun 89 16:44 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Jun 89 16:42:22 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa18914;
19 Jun 89 12:56 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA09188; Mon, 19 Jun 89 09:55:15 PDT
Date: Mon, 19 Jun 89 09:55:15 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906191655.AA09188@sesame.Stanford.EDU>
To: cph@zurich.ai.mit.edu
Cc: will@fog.cs.uoregon.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Chris Hanson's message of Fri, 2 Jun 89 15:15:37 edt <8906021915.AA02759@ZURICH.AI.MIT.EDU>
Subject: another change for R4RS; peek-char
Date: Fri, 2 Jun 89 15:15:37 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Reply-To: cph@zurich.ai.mit.edu
Date: Tue, 30 May 89 17:08:52 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
One person has objected, strongly, to making list-ref and list-tail
essential. Does anyone wish to counter by explaining just why it
is essential that these procedures be essential?
The reason is the following (extracted from the Working Group on
Scheme's unapproved minutes of the Feb. 3 meeting):
6.1 Procedures to be deleted from the standard.
Moved, seconded, and approved: keep LIST-REF, LIST-TAIL, and
SUBSTRING, and delete STRING->LIST, LIST->STRING, STRING-COPY,
STRING-FILL!, VECTOR->LIST, LIST->VECTOR, and VECTOR-FILL!. Since
LIST-REF and LIST-TAIL are non-essential features in R4RS, we need the
author's agreement to change them to essential.
This is required because the Working Group does not wish to
standardize on anything that is inessential in R*RS. If R*RS decides
to keep these procedures inessential, the WG will be forced to drop
them from the standard.
I suppose this can be thought of as a strong recommendation from the
WG to R*RS that it is desirable to keep these procedures.
In the original discussions on standardization, a concern was expressed that
the standards effort would try to foist changes on the R*RS community. We were
assured that this was not the case and any changes to R*RS would be made on
their own merits. I hope this position has not changed already!!! It is the
Working Groups decision to create a standard which only includes essential
features from R*RS. This decision should have not standing in R*RS
discussions.
Morry Katz
katz@polya.stanford.edu
∂19-Jun-89 1851 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu another change for R4RS; peek-char
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 19 Jun 89 18:51:09 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa29683;
19 Jun 89 20:04 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Jun 89 19:58:15 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12030;
19 Jun 89 19:46 EDT
Received: from ZURICH.AI.MIT.EDU ([18.43.0.172]) by life.ai.mit.edu (4.0/AI-4.10) id AA04980; Mon, 19 Jun 89 19:46:07 EDT
Return-Path: <cph@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Mon, 19 Jun 89 19:43:16 edt
Date: Mon, 19 Jun 89 19:43:16 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8906192343.AA23241@ZURICH.AI.MIT.EDU>
To: mkatz@sesame.stanford.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Morris Katz's message of Mon, 19 Jun 89 14:52:57 PDT <8906192152.AA10258@sesame.Stanford.EDU>
Subject: another change for R4RS; peek-char
Date: Mon, 19 Jun 89 14:52:57 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Maybe I reacted too strongly to this request, and I apologize to all if I did.
However, it is my opinion that a change is being advocated to R*RS based on no
technical arguments, but only political ones. At Snowbird, there were those of
us who advocated removing the functions in question from R*RS altogether and
others who wanted to make them essential. We reached a compromise that these
functions would remain inessential. I am afraid that if the question is
phrased in such a way that essential status and elimination become the only
viable alternatives, I will be forced to also break the truce and crusade for
elimination.
Again, the issue is much simpler than you are making out.
From the point of view of R*RS, the possible options are the same as
they were at Snowbird. Indeed, it entirely reasonable for the authors
group to take the position that there is no reason to change the
status quo. In that case, by decisions independent of R*RS, the
Scheme standard will *not* contain `list-ref' and `list-tail', but the
R*RS will still contain them as inessential procedures.
Let me reiterate: no one is reducing the authors' possible
alternatives or attempting to force a choice in any way.
The point of the request is that the standardization Working Group
feels that it is desirable to include these procedures in the
standard. Inclusion of the procedures requires that they be essential
in R*RS, because of the intention to make the standard a conservative
subset of R*RS. So the Working Group is asking the authors to
reconsider their decision in light of this situation, feeling that
perhaps the tide of opinion within the authors' community might shift.
A parting shot: your comment regarding technical vs. political
arguments is misleading. The comment attempts to make the (partially)
political argument of the Working Group appear unworthy of serious
consideration by the implication that previous arguments have
technical merit. As I understand it, there are few or no technical
arguments on either side of this issue; the arguments are primarily
aesthetic and/or practical. If there was a cogent technical reason
for doing things one way or the other, I suspect there would be wider
agreement about the status of these procedures.
∂19-Jun-89 1852 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu another change for R4RS; peek-char
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 19 Jun 89 18:52:00 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00281;
19 Jun 89 20:39 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Jun 89 20:37:24 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa29962;
19 Jun 89 20:24 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA10742; Mon, 19 Jun 89 17:19:51 PDT
Date: Mon, 19 Jun 89 17:19:51 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906200019.AA10742@sesame.Stanford.EDU>
To: cph@zurich.ai.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Chris Hanson's message of Mon, 19 Jun 89 19:43:16 edt <8906192343.AA23241@ZURICH.AI.MIT.EDU>
Subject: another change for R4RS; peek-char
Date: Mon, 19 Jun 89 19:43:16 edt
From: cph@ZURICH.AI.MIT.EDU (Chris Hanson)
Date: Mon, 19 Jun 89 14:52:57 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Maybe I reacted too strongly to this request, and I apologize to all if I did.
However, it is my opinion that a change is being advocated to R*RS based on no
technical arguments, but only political ones. At Snowbird, there were those of
us who advocated removing the functions in question from R*RS altogether and
others who wanted to make them essential. We reached a compromise that these
functions would remain inessential. I am afraid that if the question is
phrased in such a way that essential status and elimination become the only
viable alternatives, I will be forced to also break the truce and crusade for
elimination.
Again, the issue is much simpler than you are making out.
>From the point of view of R*RS, the possible options are the same as
they were at Snowbird. Indeed, it entirely reasonable for the authors
group to take the position that there is no reason to change the
status quo. In that case, by decisions independent of R*RS, the
Scheme standard will *not* contain `list-ref' and `list-tail', but the
R*RS will still contain them as inessential procedures.
Let me reiterate: no one is reducing the authors' possible
alternatives or attempting to force a choice in any way.
The point of the request is that the standardization Working Group
feels that it is desirable to include these procedures in the
standard. Inclusion of the procedures requires that they be essential
in R*RS, because of the intention to make the standard a conservative
subset of R*RS. So the Working Group is asking the authors to
reconsider their decision in light of this situation, feeling that
perhaps the tide of opinion within the authors' community might shift.
A parting shot: your comment regarding technical vs. political
arguments is misleading. The comment attempts to make the (partially)
political argument of the Working Group appear unworthy of serious
consideration by the implication that previous arguments have
technical merit. As I understand it, there are few or no technical
arguments on either side of this issue; the arguments are primarily
aesthetic and/or practical. If there was a cogent technical reason
for doing things one way or the other, I suspect there would be wider
agreement about the status of these procedures.
Let me attempt a short and cogent argument. It has always been my impression
that the Scheme community is attempting to create a small, but powerful, core
language on which real systems can be built. For our failure to include in
R*RS many useful functions that are easily implementable using the core
language, we have often been criticized by proponents of CommonLisp. I have
always believed that the Scheme approach was correct; however, it is my
personal opinion that if we are going to make list-tail and list-ref essential
then there are probably 50 other equivalently useful functions that should be
included in R*RS. I believe that this is a slipery slope onto which we don't
want to tread. If there is some reason that people think that these two
functions are particularly useful or are not easily implemented in the core
language, I would be very interested in hearing those arguments. Noone seemed
to be able to generate them at Snowbird.
Morry Katz
katz@polya.stanford.edu
∂19-Jun-89 1906 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu another change for R4RS; peek-char
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 19 Jun 89 19:05:56 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25509;
19 Jun 89 17:31 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Jun 89 16:59:37 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20986;
19 Jun 89 16:36 EDT
Received: from ZURICH.AI.MIT.EDU ([18.43.0.172]) by life.ai.mit.edu (4.0/AI-4.10) id AA02216; Mon, 19 Jun 89 16:36:40 EDT
Return-Path: <cph@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Mon, 19 Jun 89 16:33:22 edt
Date: Mon, 19 Jun 89 16:33:22 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8906192033.AA22514@ZURICH.AI.MIT.EDU>
To: mkatz@sesame.stanford.edu
Cc: will@fog.cs.uoregon.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Morris Katz's message of Mon, 19 Jun 89 09:55:15 PDT <8906191655.AA09188@sesame.Stanford.EDU>
Subject: another change for R4RS; peek-char
Date: Mon, 19 Jun 89 09:55:15 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Date: Fri, 2 Jun 89 15:15:37 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Reply-To: cph@zurich.ai.mit.edu
Date: Tue, 30 May 89 17:08:52 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
One person has objected, strongly, to making list-ref and list-tail
essential. Does anyone wish to counter by explaining just why it
is essential that these procedures be essential?
The reason is the following (extracted from the Working Group on
Scheme's unapproved minutes of the Feb. 3 meeting):
6.1 Procedures to be deleted from the standard.
Moved, seconded, and approved: keep LIST-REF, LIST-TAIL, and
SUBSTRING, and delete STRING->LIST, LIST->STRING, STRING-COPY,
STRING-FILL!, VECTOR->LIST, LIST->VECTOR, and VECTOR-FILL!. Since
LIST-REF and LIST-TAIL are non-essential features in R4RS, we need the
author's agreement to change them to essential.
This is required because the Working Group does not wish to
standardize on anything that is inessential in R*RS. If R*RS decides
to keep these procedures inessential, the WG will be forced to drop
them from the standard.
I suppose this can be thought of as a strong recommendation from the
WG to R*RS that it is desirable to keep these procedures.
In the original discussions on standardization, a concern was expressed that
the standards effort would try to foist changes on the R*RS community. We were
assured that this was not the case and any changes to R*RS would be made on
their own merits. I hope this position has not changed already!!! It is the
Working Groups decision to create a standard which only includes essential
features from R*RS. This decision should have not standing in R*RS
discussions.
Morry Katz
katz@polya.stanford.edu
No one is trying to "foist changes" on the R*RS community. The
standards Working Group has made a REQUEST that this be changed. If
the authors refuse the request, as is their prerogative, the Working
Group will accept that decision.
Please don't read more political intent into my message than was there
already, even if it does help to reinforce your position. I thought I
was quite clear as to the nature of the request, including the
possibility that the working group might have to deal with a refusal.
∂19-Jun-89 1907 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu another change for R4RS; peek-char
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 19 Jun 89 19:07:35 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17117;
19 Jun 89 19:27 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Jun 89 19:25:51 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa11775;
19 Jun 89 19:24 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA10258; Mon, 19 Jun 89 14:52:57 PDT
Date: Mon, 19 Jun 89 14:52:57 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906192152.AA10258@sesame.Stanford.EDU>
To: cph@zurich.ai.mit.edu
Cc: will@fog.cs.uoregon.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Chris Hanson's message of Mon, 19 Jun 89 16:33:22 edt <8906192033.AA22514@ZURICH.AI.MIT.EDU>
Subject: another change for R4RS; peek-char
Date: Mon, 19 Jun 89 16:33:22 edt
From: cph@ZURICH.AI.MIT.EDU (Chris Hanson)
Date: Mon, 19 Jun 89 09:55:15 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Date: Fri, 2 Jun 89 15:15:37 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Reply-To: cph@zurich.ai.mit.edu
Date: Tue, 30 May 89 17:08:52 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
One person has objected, strongly, to making list-ref and list-tail
essential. Does anyone wish to counter by explaining just why it
is essential that these procedures be essential?
The reason is the following (extracted from the Working Group on
Scheme's unapproved minutes of the Feb. 3 meeting):
6.1 Procedures to be deleted from the standard.
Moved, seconded, and approved: keep LIST-REF, LIST-TAIL, and
SUBSTRING, and delete STRING->LIST, LIST->STRING, STRING-COPY,
STRING-FILL!, VECTOR->LIST, LIST->VECTOR, and VECTOR-FILL!. Since
LIST-REF and LIST-TAIL are non-essential features in R4RS, we need the
author's agreement to change them to essential.
This is required because the Working Group does not wish to
standardize on anything that is inessential in R*RS. If R*RS decides
to keep these procedures inessential, the WG will be forced to drop
them from the standard.
I suppose this can be thought of as a strong recommendation from the
WG to R*RS that it is desirable to keep these procedures.
In the original discussions on standardization, a concern was expressed that
the standards effort would try to foist changes on the R*RS community. We were
assured that this was not the case and any changes to R*RS would be made on
their own merits. I hope this position has not changed already!!! It is the
Working Groups decision to create a standard which only includes essential
features from R*RS. This decision should have not standing in R*RS
discussions.
Morry Katz
katz@polya.stanford.edu
No one is trying to "foist changes" on the R*RS community. The
standards Working Group has made a REQUEST that this be changed. If
the authors refuse the request, as is their prerogative, the Working
Group will accept that decision.
Please don't read more political intent into my message than was there
already, even if it does help to reinforce your position. I thought I
was quite clear as to the nature of the request, including the
possibility that the working group might have to deal with a refusal.
Maybe I reacted too strongly to this request, and I apologize to all if I did.
However, it is my opinion that a change is being advocated to R*RS based on no
technical arguments, but only political ones. At Snowbird, there were those of
us who advocated removing the functions in question from R*RS altogether and
others who wanted to make them essential. We reached a compromise that these
functions would remain inessential. I am afraid that if the question is
phrased in such a way that essential status and elimination become the only
viable alternatives, I will be forced to also break the truce and crusade for
elimination.
Morry Katz
katz@polya.stanford.edu
∂19-Jun-89 2242 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #141
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 19 Jun 89 22:42:11 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25176;
20 Jun 89 1:12 EDT
Date: 20 JUN 89 00:07:16 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #141
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8906200112.aa25176@mintaka.lcs.mit.edu>
Scheme Digest #141 20 JUN 89 00:07:16 EDT
Today's Topics:
"unspecified" and SET!
"unspecified" and SET!
----------------------------------------------------------------------
Date: Mon, 19 Jun 89 15:26 EDT
From: Alan Bawden <Alan@REAGAN.AI.MIT.EDU>
Subject: "unspecified" and SET!
Message-ID: <19890619192610.2.ALAN@PIGPEN.AI.MIT.EDU>
Date: 18 Jun 89 23:17:50 GMT
From: Dorai Sitaram <titan!dorai@rice.edu>
...
Perhaps, SET! is not the ideal side-effecting construct for an
expression-oriented language. Felleisen and Friedman [1] propose a
side-effecting construct called a SIGMA-capability. This looks just
like a LAMBDA-expression, but whereas LAMBDA introduces new bound
variables, SIGMA modifies the binding of existing lexical variables.
In other words, on applying a SIGMA-capability to arguments, the
variables corresponding to the SIGMA-parameters are side-effected.
Problems about "unspecified" return values disappear....
I'm having a hard time applying this idea to the NEWLINE procedure -- which
is specified in R3RS to return an unspecified value. Is the idea to
introduce a side-effecting construct that looks like LAMBDA, but performs a
newline when applied to an output port?
((NULINE () <body>)
(CURRENT-OUTPUT-PORT))
------------------------------
Date: 19 Jun 89 23:24:37 GMT
From: Dorai Sitaram <titan!dorai@rice.edu>
Subject: Re: "unspecified" and SET!
Message-Id: <3904@kalliope.rice.edu>
In response to my posting suggesting SIGMA and SIGMA-based SET! (a la
LAMBDA and LET) instead of traditional SET!, I received email which
basically states that SIGMA violates the orthogonality of Scheme
constructs, viz., SIGMA does "two" things: it "side-effects the
environment" _and_ "returns a value".
In other words, it is felt that any side-effecting construct should
just perform the job it was made for, viz., side-effecting, and not do
something else too, like returning values. SIGMA allegedly "fails" in
the latter detail.
But then, we should remember that our goal was to preserve the
syntactic uniformity of Scheme. Scheme is (and very deliberately too)
an expression-oriented language. In spite of our best efforts,
traditional SET! does return a value. Given that whichever primitive
side-effecting construct we pick will inevitably return a value, which
construct should we choose? I would prefer one where the returned
value is not only meaningful but _necessary_.
The value that SET! returns is totally arbitrary. What SIGMA returns
is crucial to its correctness. Recall that SIGMA does not perform a
side-effect immediately; it returns a closure, which needs to be
applied to value(s) before any side-effecting can take place.
(Incidentally, LAMBDA, the cornerstone of Scheme, also has "two"
purposes _if_ we take "returning a value" as a distinguishing property
in assessing the orthogonality of Scheme. LAMBDA introduces fresh
lexical variables _and_ returns a closure. I don't think anyone
seriously wants to reject LAMBDA for lack of orthogonality!)
--dorai
ps: Other questions:
* Why was SIGMA created? Felleisen & Friedman (POPL 1987) devised a
calculus for a lambda-calculus-like language with assignments. SIGMA
kind of falls out naturally.
* Why is it "superior" to SET!? "Superior" is a tough word. However, I
did mention the naturalness of parallel assignment in my orig.
posting. Using SIGMA-capabilities as arguments to control-reifiers
like call/cc is also delicious.
* There is also another reason why the SIGMA-model of assignment, viz.,
(sigma (x ...) e ...) or (set! ([x a] ...) e ...), makes sense. In any
program, one always performs some operation _after_ the
side-effecting (of variable-bindings(see + below)) has been done. If
the side-effecting were the last thing done in the program, there is
no way it could be detected, hence no way it could be meaningful.
Thus the application of a SIGMA-capability returns the value of the
body of the SIGMA-expression, something (and such a something
invariably exists) that is evaluated _after_ the side-effecting has
taken place.
+{PRINTF is the only side-effect which can meaningfully be the last
thing in a program.}
* [Alan Bawden's question about NEWLINE...]
How do you deal with the other "commands" of Scheme? (E.g., READ,
SET-CAR!, PRINTF.) Easier than SET!. SIGMA-like counterparts need
_not_ be made for these, as that would lead to a plethora of special
forms (as opposed to 'procedures'). All of these "command"
procedures now take an additional argument for "the body" (thunk
actually) whose value is returned.
{* SIGMA of course is necessarily a special form (i.e., it cannot be
substituted by a procedure as for READ, SET-CAR!, PRINTF above).
The reason is variable names can't be passed as procedure arguments.}
--dorai
-------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
-------------------------------------------------------------------------------
------------------------------
End of Scheme Digest
********************
∂20-Jun-89 0721 @mc.lcs.mit.edu:shaff@sesame.stanford.edu Useful, but not essential
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89 07:21:30 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id ab06077;
20 Jun 89 10:17 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Jun 89 10:14:15 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa19354;
20 Jun 89 10:10 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA13286; Tue, 20 Jun 89 07:09:44 PDT
Date: Tue, 20 Jun 89 07:09:44 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8906201409.AA13286@sesame.Stanford.EDU>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Useful, but not essential
ciao,
I hesitate to enter into this seemingly charged arena, but...
It is my opinion that non-essential procedures, were to be considered
potentially useful for the user, hence implementors were given a possible
binding for the specified functionality. This was a method by which we could
avoid having standard 'user environment' procedures with wildly divergent
names/functionality.
I must admit my bias away from the inclusion of easily built procedures (and
macros, someday... ahhh someday ;>). If one looks at the Brooks and Gabriel
paper entitled 'A Critique of Common Lisp' (reference below) the first
desirable property is written of as:
Intellectual Conciseness. A language should be small enough for a programmer
to be able to keep all of it in mind when programming.
I recognize that the introduction of essential procedures does not introduce
primitives (the focus of Brooks and Gabriel's paragraph), however I do think
that the principle can be applied here. (NOTE: I was one of the people that
advocated the complete removal of a number of non-essential constructs).
I share Chris Hansons's hope that this (and all future) discussions return to
a tone of tech/fun.
(peace chance)
mas
∂20-Jun-89 0754 @mc.lcs.mit.edu:shaff@sesame.stanford.edu Useful, but not essential: the reference
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89 07:54:35 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa14878;
20 Jun 89 10:35 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Jun 89 10:19:48 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa04769;
20 Jun 89 10:16 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA13322; Tue, 20 Jun 89 07:16:22 PDT
Date: Tue, 20 Jun 89 07:16:22 PDT
From: shaff@sesame.stanford.edu (Mike Shaff)
Message-Id: <8906201416.AA13322@sesame.Stanford.EDU>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Useful, but not essential: the reference
ciao,
Not being of sound mind I forgot the promised reference.
Brooks, R. A. & Gabriel R. P., A Critique of Common Lisp, Proceedings of 1984
Symposium on LISP and Functional Programming, ACM, New York, 1984.
(peace chance)
mas
∂20-Jun-89 1323 @mc.lcs.mit.edu,@zermatt.lcs.mit.edu:ziggy@hx.lcs.mit.edu RE: Sticks and stones
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89 13:23:48 PDT
Received: by mintaka.lcs.mit.edu id af03592; 20 Jun 89 16:08 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03474;
20 Jun 89 16:01 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 20 Jun 89 15:59:32 EDT
Received: from HX.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 267427; 20 Jun 89 15:58:29 EDT
Received: by hx.LCS.MIT.EDU (5.51/4.7); Tue, 20 Jun 89 15:58:40 EDT
Date: Tue, 20 Jun 89 15:58:40 EDT
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
Message-Id: <8906201958.AA15522@hx.LCS.MIT.EDU>
To: rrrs-authors@zermatt.lcs.mit.edu
Subject: RE: Sticks and stones
I vaguely recall an agreement a short time ago that there was going to
be a Standard Library of Scheme procedures. It was my understanding at the
time that all inessential procedures were going to be migrated to this
section (this may have been a halucination on my part).
Perhaps we could rechannel our hostilities between the Standards folks
and the R* folks into fulfilling that unforced promise to all submit
useful nonessential stuff to the Librarian.
This should also stimulate a discussion among the standards folks on
whether the R* Standardized Library stuff should be in the Standard
or not. That, I think, should be the sole issue to be discussed...
blackmailing the R* folks should not be the issue (you know, ``if
you folks don;t make this essential in *your* report then you can't
have it in *our* standard''. That is the ultimatum as I see it.)
Is focussing on the Library a viable alternative to sticks and stones
or am I just tossing another stick/stone?
This is not a flame. ~Ziggy
∂20-Jun-89 1424 @mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:jinx@zurich.ai.mit.edu Sticks and stones
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89 14:24:17 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa14327;
20 Jun 89 17:04 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 20 Jun 89 17:02:14 EDT
Received: from ZURICH.AI.MIT.EDU (CHAMARTIN.AI.MIT.EDU) by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 267471; 20 Jun 89 17:01:11 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Tue, 20 Jun 89 16:58:22 edt
Date: Tue, 20 Jun 89 16:58:22 edt
From: "Guillermo J. Rozas" <jinx@zurich.ai.mit.edu>
Message-Id: <8906202058.AA02376@ZURICH.AI.MIT.EDU>
To: ziggy@hx.lcs.mit.edu
Cc: rrrs-authors@ZERMATT.lcs.mit.edu
In-Reply-To: "Michael R. Blair"'s message of Tue, 20 Jun 89 15:58:40 EDT <8906201958.AA15522@hx.LCS.MIT.EDU>
Subject: Sticks and stones
Reply-To: jinx@zurich.ai.mit.edu
I'm confused about the perceived ultimatum and hostilities between the
IEEE and RnRS communities.
To start with, please remember that the intersection between the IEEE
working group and the RnRS community is almost exactly the IEEE WG.
Thus this is internal fighting inside the RnRS community.
Second, some of you have perceived the request to reexamine the
decision to make the LIST-MUMBLEs essential as an ultimatum. It is
nothing of the sort, nor does it want to be.
The IEEE WG decided that the procedures were usefuly enough that they
deserved to be in the standard. Note that the decision of exactly
what set of procedures to standardize over is purely a matter of
aesthetics and practicality, never a technical reason. While everyone
(as far as I know) agrees that we should standardize on LENGTH, it is
obvious that other procedures are much more controversial.
The WG has very strong feelings about making the IEEE draft standard a
strict subset of the essential subset of the appropriate RnRS. It
therefore politely requested reexamination of the decision to make the
LIST-MUMBLEs essential. The answer came back saying NO. There was no
intended coercion or anything after that. Why all the antagonism?
Please calm down, and READ the messages being sent.
∂20-Jun-89 1428 @mc.lcs.mit.edu,@zermatt.lcs.mit.edu:mkatz@sesame.stanford.edu Sticks and stones
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89 14:27:58 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa29905;
20 Jun 89 16:56 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 20 Jun 89 16:31:55 EDT
Received: from sesame.Stanford.EDU (INTERNET|36.22.0.169) by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 267450; 20 Jun 89 16:30:43 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA14897; Tue, 20 Jun 89 13:29:37 PDT
Date: Tue, 20 Jun 89 13:29:37 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906202029.AA14897@sesame.Stanford.EDU>
To: ziggy@hx.lcs.mit.edu
Cc: rrrs-authors@zermatt.lcs.mit.edu
In-Reply-To: "Michael R. Blair"'s message of Tue, 20 Jun 89 15:58:40 EDT <8906201958.AA15522@hx.LCS.MIT.EDU>
Subject: Sticks and stones
Date: Tue, 20 Jun 89 15:58:40 EDT
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
I vaguely recall an agreement a short time ago that there was going to
be a Standard Library of Scheme procedures. It was my understanding at the
time that all inessential procedures were going to be migrated to this
section (this may have been a halucination on my part).
Perhaps we could rechannel our hostilities between the Standards folks
and the R* folks into fulfilling that unforced promise to all submit
useful nonessential stuff to the Librarian.
This should also stimulate a discussion among the standards folks on
whether the R* Standardized Library stuff should be in the Standard
or not. That, I think, should be the sole issue to be discussed...
blackmailing the R* folks should not be the issue (you know, ``if
you folks don;t make this essential in *your* report then you can't
have it in *our* standard''. That is the ultimatum as I see it.)
Is focussing on the Library a viable alternative to sticks and stones
or am I just tossing another stick/stone?
This is not a flame. ~Ziggy
I strongly support your call for resurrecting the library (yellow pages).
Somehow the library seems to have died, I suspect as a result of the lack of a
standard macro facility. Many of the things people wanted to place in the
library cannot be written in an implementation independent fashion (i.e., in
R*RS) without standard macros. Therefore, lets get macros and the library
going ASAP.
Morry Katz
katz@polya.stanford.edu
∂20-Jun-89 1437 @MC.lcs.mit.edu,@life.ai.mit.edu:Stewart.Clamen@clamen.avalon.cs.cmu.edu LIST-REF and LIST-TAIL
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89 14:37:27 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id ac01489;
20 Jun 89 17:15 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Jun 89 17:08:27 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id ab12917;
20 Jun 89 17:03 EDT
Received: from ZURICH.AI.MIT.EDU by life.ai.mit.edu (4.0/AI-4.10) id AA03103; Tue, 20 Jun 89 17:03:11 EDT
Return-Path: <Stewart.Clamen@clamen.avalon.cs.cmu.edu>
Received: from CLAMEN.AVALON.CS.CMU.EDU ([128.2.220.41]) by ZURICH.AI.MIT.EDU; Tue, 20 Jun 89 17:00:22 edt
Message-Id: <8906202100.AA02883@ZURICH.AI.MIT.EDU>
Date: Tue, 20 Jun 89 17:02:10 EDT
From: Stewart.Clamen@cs.cmu.edu
To: scheme-standard@zurich.ai.mit.edu
Cc: rrrs-authors@zurich.ai.mit.edu
Subject: LIST-REF and LIST-TAIL
Reply-To: clamen@cs.cmu.edu
Does anyone who was at the last Standardization meeting remember the
motivations which led to our desire to have LIST-REF and LIST-TAIL in
the language (and thus resulting in a request of the R*RS Group to
promote the two procedures from "optional" to "essential")? I was
there, but I cannot recall the discussion that led to this decision.
Perhaps if those ideas were resurrected now for the benefit of R*RS,
we might be able to resolve this issue and get on to more important
things?
SMC
P.S. I really don't want to send this to BOTH lists, but what choice
do I have?
∂20-Jun-89 1500 @mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:cph@ZURICH.ai.mit.edu Sticks and stones
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89 14:59:52 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16724;
20 Jun 89 17:50 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 20 Jun 89 17:48:00 EDT
Received: from ZURICH.AI.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 267499; 20 Jun 89 17:47:00 EDT
Return-Path: <cph@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Tue, 20 Jun 89 17:44:14 edt
Date: Tue, 20 Jun 89 17:44:14 edt
From: Chris Hanson <cph@ZURICH.ai.mit.edu>
Message-Id: <8906202144.AA03583@ZURICH.AI.MIT.EDU>
To: jinx@ZURICH.ai.mit.edu
Cc: rrrs-authors@ZERMATT.lcs.mit.edu
In-Reply-To: "Guillermo J. Rozas"'s message of Tue, 20 Jun 89 16:58:22 edt <8906202058.AA02376@ZURICH.AI.MIT.EDU>
Subject: Sticks and stones
Date: Tue, 20 Jun 89 16:58:22 edt
From: "Guillermo J. Rozas" <jinx@zurich.ai.mit.edu>
It
therefore politely requested reexamination of the decision to make the
LIST-MUMBLEs essential. The answer came back saying NO.
More precisely: some members of the authors committee have replied NO.
∂20-Jun-89 1542 @mc.lcs.mit.edu,@zermatt.lcs.mit.edu:mkatz@sesame.stanford.edu Sticks and stones
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89 15:39:19 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05171;
20 Jun 89 18:27 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 20 Jun 89 18:25:21 EDT
Received: from SESAME.STANFORD.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 267520; 20 Jun 89 18:24:16 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA15385; Tue, 20 Jun 89 15:23:41 PDT
Date: Tue, 20 Jun 89 15:23:41 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906202223.AA15385@sesame.Stanford.EDU>
To: rrrs-authors@zermatt.lcs.mit.edu
In-Reply-To: Chris Hanson's message of Tue, 20 Jun 89 17:44:14 edt <8906202144.AA03583@ZURICH.AI.MIT.EDU>
Subject: Sticks and stones
The general consensus seems to be that my original message on list-tail and
list-ref read much more strongly than I intended. Again, my sincerest
apologies to cph and anyone else in the WG who I offended. I only wanted to
express my feeling that standardization should not carry any more weight in
R*RS discussions than that which would normally be given to members of
the WG as members of the R*RS community. I continue to believe that list-tail
and list-ref should not become essential procedures, but not at the expense of
losing friends. There are more important battles to be fought.
Morry Katz
katz@polya.stanford.edu
∂20-Jun-89 1644 @mc.lcs.mit.edu,@life.ai.mit.edu,@fog.cs.uoregon.edu:will@cs.uoregon.edu LIST-REF, LIST-TAIL
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89 16:44:11 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07266;
20 Jun 89 19:34 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Jun 89 19:32:57 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07207;
20 Jun 89 19:27 EDT
Received: from ZURICH.AI.MIT.EDU by life.ai.mit.edu (4.0/AI-4.10) id AA05327; Tue, 20 Jun 89 19:27:03 EDT
Return-Path: <@fog.cs.uoregon.edu:will@cs.uoregon.edu>
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by ZURICH.AI.MIT.EDU; Tue, 20 Jun 89 19:24:08 edt
Received: from fog.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA14125; Tue, 20 Jun 89 16:26:27 PDT
Received: by fog.cs.uoregon.edu; Tue, 20 Jun 89 16:24:24 PDT
Date: Tue, 20 Jun 89 16:24:24 PDT
From: will@cs.uoregon.edu
Message-Id: <8906202324.AA11051@fog.cs.uoregon.edu>
To: cph@zurich.ai.mit.edu
Subject: LIST-REF, LIST-TAIL
Cc: rrrs-authors@zurich.ai.mit.edu
Chris, I think it would help the authors if you could explain why the
P1178 group feels that LIST-REF and LIST-TAIL need to be in the IEEE
standard. Right now the only thing we've got to go on is the fact that
P1178 has requested that they be made essential. As an editor of R4RS,
I don't feel comfortable making that change (in the face of a contrary
decision at Snowbird and an objection recently registered on rrrs-authors)
without some kind of technical rationale.
Peace, Will
∂20-Jun-89 2306 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #142
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89 23:06:44 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12949;
21 Jun 89 1:19 EDT
Date: 21 JUN 89 00:08:03 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #142
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8906210119.aa12949@mintaka.lcs.mit.edu>
Scheme Digest #142 21 JUN 89 00:08:03 EDT
Today's Topics:
"unspecified" and SET!
"unspecified" and SET!
"unspecified" and SET!
----------------------------------------------------------------------
Date: 20 Jun 89 01:48:58 GMT
From: Vincent Manis <att!alberta!ubc-cs!grads.cs.ubc.ca!manis@bloom-beacon.mit.edu>
Subject: Re: "unspecified" and SET!
Message-Id: <2281@ubc-cs.UUCP>
I've bitten my tongue on this, but I really can't see the point of
#!unspecified. Perhaps it would be nice in theory (especially if
(define loop
(lambda (x)
(loop (1+ x))))
returned #!unspecified, which would then be equivalent to `bottom' in
the Scott-Strachey world), but it seems pointless.
One can argue, as somebody has, that the existing behaviour
distinguishes between expressions and commands; however, Scheme already
has a strong notion of side effects (unlike, say, Miranda), and
whether a side-effecting procedure yields (), #f, an unspecified
result, or #!unspecified really makes no difference to anybody, except
in one place, which I'll mention in a moment.
I regard `returns an unspecified result' as an injunction not to place
a call to a procedure in a value-returning position, e.g., the last
step in a lambda or begin. If I wrote a Scheme compiler, fascist that
I am, I would probably generate an error message for such a usage.
Going to the trouble to develop a calculus of unspecified values
strikes me as almost as silly as some of the things I did when I was
involved in writing an Algol 68 compiler.
The one place where #!unspecified makes some sense is in
Read-Eval-Print loops. One can use #!unspecified as a trigger that the
result is not to be printed. But then one does not need to change the
language: PC Scheme, for example, has *the-non-printing-object*.
If it ain't broke, don't fix it.
____________ Vincent Manis | manis@cs.ubc.ca
___ \ _____ The Invisible City of Kitezh | manis@cs.ubc.cdn
____ \ ____ Department of Computer Science | manis%cs.ubc@relay.cs.net
___ /\ ___ University of British Columbia | uunet!ubc-cs!manis
__ / \ __ Vancouver, BC, Canada V6T 1W5 | (604) 228-2394
_ / __ \ _ "Theoretical computer science helps me convince people that
____________ my indecisiveness is really Nondeterminism, which sounds like
a much more positive characteristic." -- a student
------------------------------
Date: 20 Jun 89 16:29:44 GMT
From: Brad Pierce <pierce@locus.ucla.edu>
Subject: Re: "unspecified" and SET!
Message-Id: <25058@shemp.CS.UCLA.EDU>
In article <2281@ubc-cs.UUCP> manis@grads.cs.ubc.ca (Vincent Manis) writes:
<< Stuff omitted. >>
>I regard `returns an unspecified result' as an injunction not to place
>a call to a procedure in a value-returning position, e.g., the last
>step in a lambda or begin. If I wrote a Scheme compiler, fascist that
>I am, I would probably generate an error message for such a usage.
<< Stuff omitted. >>
This is really not a criticsm, only a question. How does one go about
building a compiler that can detect when a procedure is going to
return an unspecified result, especially those which sometime return
unspecified values and sometimes return specified values? For example,
in an object-oriented program most objects will respond to some
messages with actual information and to some messages with unspecified
values. On the face of it, it sounds very difficult to determine such
things syntactically. And wouldn't runtime checking amount to
introducing the unspecified object?
It doesn't seem right to me that a user should have to know the
full specifications of an object before being able to confidently
send messages to that object. It would seem preferable to me to
be able to check whether the result returned has any information
content.
Also in this discussion I haven't heard any mention of my suggestion
to see the unspecified object as being analogous to NaN in the IEEE
numeric standard. Is that a bad analogy? Is NaN a bad idea? Just
wondering.
-- Brad
------------------------------
Date: Tue, 20 Jun 89 18:15:21 EDT
From: Alan Bawden <ALAN%ML.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
Subject: "unspecified" and SET!
Message-ID: <10160.890620.ALAN@ML.AI.MIT.EDU>
Date: 19 Jun 89 23:24:37 GMT
From: Dorai Sitaram <titan!dorai@rice.edu>
How do you deal with the other "commands" of Scheme? (E.g., READ,
SET-CAR!, PRINTF.) Easier than SET!. SIGMA-like counterparts need
_not_ be made for these, as that would lead to a plethora of special
forms (as opposed to 'procedures'). All of these "command"
procedures now take an additional argument for "the body" (thunk
actually) whose value is returned.
So we would write
(NEWLINE (CURRENT-OUTPUT-PORT)
(LAMBDA ()
(WRITE X (CURRENT-OUTPUT-PORT)
(LAMBDA () X))))
to newline, and then output and return the current value of X. (Or perhaps
the continuations are passed as the first argument -- it doesn't matter in
the current discussion.)
Now it would seem to me that the most uniform way to include assignment in
this scheme, is to have SET! take a continuation as well. So
(SET! X (+ X 1)
(LAMBDA () X))
would increment the value of X and return the new value.
SET! is still a keyword, so this isn't -exactly- parallel with the
side-effecting procedures. But I'll bet that once people start writing
programs using this scheme, the thing that will impress them the most is
that whenever they perform a side-effect they have to create an explicit
continuation to wait for the side-effect to happen. And I'll bet they will
be most comfortable if they have to make exactly the same kind of
continuation for SET!.
I'm currently working on a language where users really -must- control
sequencing by explicitly using thunks, so I'm very interested in linguistic
constructs that support this style. Actually, in my case its worse than in
plain Scheme, because users must also exert control over when variables are
-read- as well as written. Thus users have to write something like
(LOOK! X
(LAMBDA (VALUE)
(SET! X (+ 1 VALUE)
(LAMBDA ()
<whatever>
))))
to increment the value of X, because if they wrote
(SET! X (+ 1 X)
(LAMBDA ()
<whatever>
))
the occurrence of X in (+ 1 X) might be taken to refer to the value of X
-after- the SET! happens (so that the value of X would become the fixed
point of (lambda (n) (+ 1 n))!).
------------------------------
End of Scheme Digest
********************
∂21-Jun-89 1450 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@zurich.ai.mit.edu Librarian
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 21 Jun 89 14:50:32 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00767;
21 Jun 89 17:27 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jun 89 17:24:49 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa11988;
21 Jun 89 17:18 EDT
Received: from ZURICH.AI.MIT.EDU by life.ai.mit.edu (4.0/AI-4.10) id AA00513; Wed, 21 Jun 89 17:01:12 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Wed, 21 Jun 89 13:25:19 edt
Date: Wed, 21 Jun 89 13:25:19 edt
From: "Guillermo J. Rozas" <jinx@zurich.ai.mit.edu>
Message-Id: <8906211725.AA13445@ZURICH.AI.MIT.EDU>
To: rrrs-authors%mc.lcs.mit.edu@life.ai.mit.edu
Subject: Librarian
Reply-To: jinx@zurich.ai.mit.edu
Jonathan Rees has offered to be the next Scheme librarian.
The original term was supposed to be 6 months, but it has been two years
since I was appointed, it is probably high time for someone
(especially a more activist person) to replace me.
I don't know what the proper procedure to arrane for succession is but
I guess at the very least the following steps must be taken:
1) Ask for any other interested parties. Is there anyone else?
2) Vote on a new librarian among the interested parties. This is moot
if there are no other interested parties, or they are willing to defer
to JAR.
If I don't hear from anyone else in the next two weeks, I will assume
that no one will contest Jonathan's appointment, and will send a message
announcing this fact.
∂21-Jun-89 1457 @mc.lcs.mit.edu,@life.ai.mit.edu:Gateley@tilde.csc.ti.com Re: LIST-REF and LIST-TAIL
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 21 Jun 89 14:56:14 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05698;
21 Jun 89 17:38 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jun 89 17:30:51 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa18618;
21 Jun 89 17:21 EDT
Received: from ZURICH.AI.MIT.EDU by life.ai.mit.edu (4.0/AI-4.10) id AA00412; Wed, 21 Jun 89 16:58:06 EDT
Return-Path: <Gateley@tilde.csc.ti.com>
Received: from ti.com (ti.com) by ZURICH.AI.MIT.EDU; Wed, 21 Jun 89 16:52:40 edt
Received: by ti.com id AA05959; Wed, 21 Jun 89 10:33:55 CDT
Received: from Casablanca by tilde id AA13214; Wed, 21 Jun 89 10:24:24 CDT
Message-Id: <2823434649-13090092@Casablanca>
Sender: GATELEY@casablanca.csc.ti.com
Date: Wed, 21 Jun 89 10:24:09 CDT
From: John Gateley <Gateley@tilde.csc.ti.com>
To: clamen@cs.cmu.edu
Cc: rrrs-authors@zurich.ai.mit.edu, scheme-standard@zurich.ai.mit.edu
Subject: Re: LIST-REF and LIST-TAIL
In-Reply-To: Msg of Tue, 20 Jun 89 17:02:10 EDT from Stewart.Clamen@cs.cmu.edu
>Does anyone who was at the last Standardization meeting remember the
>motivations which led to our desire to have LIST-REF and LIST-TAIL in
>the language (and thus resulting in a request of the R*RS Group to
>promote the two procedures from "optional" to "essential")?
As secretary for the last meeting, I have dug out my notes:
The arguments for:
There is vector-ref and string-ref, so there should be list-ref.
This conforms to Will C's law of least surprises.
These can be implemented more efficiently than the naive way if
the implementation uses cdr-coding. (And efficiency can be
considered an important issue, consider substring).
They provide continuity of error condition for reading past the end
with vector- and string-ref.
The arguments against:
They can be implemented trivially in terms of car and cdr.
They belong in an appendix (the response to this was that an
appendix is not binding).
Lists and vectors are not the same, so we shouldn't be concerned with
uniformity between them.
A final comment: At the point where it was clear that list-ref was going
to be kept, it was mentioned that list-tail should be kept too.
Hope this helps,
John
gateley@m2.csc.ti.com or gateley@csc.ti.com or gateley@zoo.csc.ti.com
∂21-Jun-89 2238 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #143
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 21 Jun 89 22:38:19 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09436;
22 Jun 89 1:04 EDT
Date: 22 JUN 89 00:08:41 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #143
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8906220104.aa09436@mintaka.lcs.mit.edu>
Scheme Digest #143 22 JUN 89 00:08:41 EDT
Today's Topics:
Scheme Digest #125
"unspecified" and SET!
"unspecified" and SET!
----------------------------------------------------------------------
Date: Wed, 21 Jun 89 15:48 EDT
From: Andre van Meulebrouck <vanMeule@allegheny.scrc.symbolics.com>
Subject: Scheme Digest #125
Message-ID: <19890621194848.5.VANMEULE@PERTA.SCRC.Symbolics.COM>
Date: Thu, 25 May 89 02:27:13 -0700
From: "Jonathan S. Shapiro" <shap@polya.stanford.edu>
Very well. I hereby specify an object whose name is
#UNSPECIFIED
Any association between this name and some meaning in your mind is
coincidental. I propose that all functions/forms that under some
conditions currently return an unspecified value should now return a
value which is EQ? to the value named by #UNSPECIFIED under those same
conditions.
Note that you are only in violation of R3RS if you *tell* me that that
is what you do...
Seriously: It's a non-damaging change, and there seems to be concensus
that it is valuable to some part of the community and has no impact to
speak of on anyone else.
Let's do it.
Jon
[Disclaimer: my opinions are purely my own.]
An off-the-cuff comment after seeing the argument posed that way (↑↑) is: "Why
not? After all there is canonical truth!".
I see a lot of parallels between canonical unspecified and canonical truth.
I'm not taking sides however, because my jury's still out and/or I don't care
enough to get really religious one way or the other about it.
BTW: I think the whole thing with nil vs. () vs. #f got a lot of mental energy
spent on it, and even after all that mind power being focused on that issue, I'm
still not convinced that things are now consistent or appreciably cleaner than
before: the net outcome seems to have hypocrisies of its own such that I'm not
convinced Scheme is truly better off than Common Lisp (on the nil issue) for all
the hubbub and hoopla.
------------------------------
Date: Wed, 21 Jun 89 14:17:54 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906212117.AA20117@sesame.Stanford.EDU>
Subject: "unspecified" and SET!
At the R*RS meeting in Snowbird we discussed the possibility of adding some
form of multiple values to Scheme and allowing continuations to accept multiple
values. I wonder if the solution to the problem of what should be returned by
side effecting procedures like SET! is to just have them return no values (i.e.
a zero arity multiple value). As long as continuations can handle multiple
values appropriately, it seems to me that this solution would have many, if not
all, of the advantages of #!UNSPECIFIED without introducing many of the
undesirable side effects.
Morry Katz
katz@polya.stanford.edu
P.S. After the meeting at Snowbird, Guy Steele and I came to an agreement as
to the correct of the two conflicting semantics for multiple values to
continuations that we proposed. At that time, we believed that this
solution would probably be acceptable to the great majority of the
community. Is there interest in having the proposal written up for
future consideration? I would be willing to strain my memory in an
attempt to creat such a proposal if there is genuine interest.
------------------------------
Date: 21 Jun 89 22:47:44 GMT
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
Subject: Re: "unspecified" and SET!
Message-Id: <CHAYNES.89Jun21174744@iuvax.cs.indiana.edu>
From: mkatz@SESAME.STANFORD.EDU (Morris Katz)
Newsgroups: comp.lang.scheme
Date: 21 Jun 89 21:17:54 GMT
...
P.S. After the meeting at Snowbird, Guy Steele and I came to an agreement as
to the correct of the two conflicting semantics for multiple values to
continuations that we proposed. At that time, we believed that this
solution would probably be acceptable to the great majority of the
community. Is there interest in having the proposal written up for
future consideration? I would be willing to strain my memory in an
attempt to creat such a proposal if there is genuine interest.
I'm interested.
------------------------------
End of Scheme Digest
********************
∂22-Jun-89 0706 @mc.lcs.mit.edu,@mojave.stanford.edu:shap@sid.stanford.edu Useful, but not essential
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 22 Jun 89 07:06:13 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26763;
22 Jun 89 9:50 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Jun 89 09:46:09 EDT
Received: from Mojave.Stanford.EDU by mintaka.lcs.mit.edu id aa26569;
22 Jun 89 9:38 EDT
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
id AA22682; Thu, 22 Jun 89 06:36:10 PDT
Message-Id: <8906221336.AA22682@mojave.Stanford.EDU>
Received: by sid; Thu, 22 Jun 89 06:38:39 pdt
Date: Thu, 22 Jun 89 06:38:39 pdt
From: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
To: shaff@sesame.stanford.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Mike Shaff's message of Tue, 20 Jun 89 07:09:44 PDT <8906201409.AA13286@sesame.Stanford.EDU>
Subject: Useful, but not essential
From: Mike Shaff <shaff@sesame.stanford.edu>
It is my opinion that non-essential procedures, were to be considered
potentially useful for the user, hence implementors were given a possible
binding for the specified functionality. This was a method by which we
could avoid having standard 'user environment' procedures with wildly
divergent names/functionality.
Normally, I am inclined to agree with Mike's views. From the
perspective of someone who is interested in writing portable Scheme
programs, however, I cannot overemphasize the desirability of
standardizing certain common functionality even though it is not
strictly necessary.
*If* there existed a standard Scheme library, then I would certainly
accept the view that LIST-REF and LIST-TAIL should be part of the
library and not part of the language. In the absence of such a
library, preserving them seems warranted because of their utility.
Jon Shapiro
∂22-Jun-89 1210 @MC.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu LIST-REF and LIST-TAIL
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 22 Jun 89 12:10:08 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01255;
22 Jun 89 15:01 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Jun 89 14:59:17 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa01178;
22 Jun 89 14:55 EDT
Received: from ZURICH.AI.MIT.EDU by life.ai.mit.edu (4.0/AI-4.10) id AA00684; Thu, 22 Jun 89 14:53:42 EDT
Return-Path: <mkatz@sesame.Stanford.EDU>
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by ZURICH.AI.MIT.EDU; Thu, 22 Jun 89 14:50:44 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA24530; Thu, 22 Jun 89 11:52:42 PDT
Date: Thu, 22 Jun 89 11:52:42 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906221852.AA24530@sesame.Stanford.EDU>
To: Gateley@tilde.csc.ti.com
Cc: clamen@cs.cmu.edu, rrrs-authors@zurich.ai.mit.edu,
scheme-standard@zurich.ai.mit.edu
In-Reply-To: John Gateley's message of Wed, 21 Jun 89 10:24:09 CDT <2823434649-13090092@Casablanca>
Subject: LIST-REF and LIST-TAIL
Sender: GATELEY@casablanca.csc.ti.com
Date: Wed, 21 Jun 89 10:24:09 CDT
From: John Gateley <Gateley@tilde.csc.ti.com>
>Does anyone who was at the last Standardization meeting remember the
>motivations which led to our desire to have LIST-REF and LIST-TAIL in
>the language (and thus resulting in a request of the R*RS Group to
>promote the two procedures from "optional" to "essential")?
As secretary for the last meeting, I have dug out my notes:
The arguments for:
There is vector-ref and string-ref, so there should be list-ref.
This conforms to Will C's law of least surprises.
These can be implemented more efficiently than the naive way if
the implementation uses cdr-coding. (And efficiency can be
considered an important issue, consider substring).
They provide continuity of error condition for reading past the end
with vector- and string-ref.
The arguments against:
They can be implemented trivially in terms of car and cdr.
They belong in an appendix (the response to this was that an
appendix is not binding).
Lists and vectors are not the same, so we shouldn't be concerned with
uniformity between them.
A final comment: At the point where it was clear that list-ref was going
to be kept, it was mentioned that list-tail should be kept too.
Hope this helps,
John
gateley@m2.csc.ti.com or gateley@csc.ti.com or gateley@zoo.csc.ti.com
As part of an attempt to strive for uniformity, I was appointed to fill in the
gaps to make lists, vectors, and strings uniform for R4RS. I sent out a
proposal on this many moons ago and got no responses or comments. What ever
happened? Did people give up on this idea? It seems pertinent since
uniformity would require a vector-tail analogous to list-tail. Somehow
vector-tail rubs me wrong.
Morry Katz
katz@polya.stanford.edu
∂22-Jun-89 1257 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu [chaynes@iuvax.cs.indiana.edu: [will@cs.uoregon.edu: LIST-REF, LIST-TAIL]]
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 22 Jun 89 12:57:48 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01860;
22 Jun 89 15:51 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Jun 89 15:48:28 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa01819;
22 Jun 89 15:45 EDT
Received: from ZURICH.AI.MIT.EDU ([18.43.0.172]) by life.ai.mit.edu (4.0/AI-4.10) id AA02172; Thu, 22 Jun 89 15:44:38 EDT
Return-Path: <cph@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Thu, 22 Jun 89 15:41:49 edt
Date: Thu, 22 Jun 89 15:41:49 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8906221941.AA27917@ZURICH.AI.MIT.EDU>
To: rrrs-authors@mc.lcs.mit.edu
Subject: [chaynes@iuvax.cs.indiana.edu: [will@cs.uoregon.edu: LIST-REF, LIST-TAIL]]
Date: Wed, 21 Jun 89 17:38:18 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: cph@ZURICH.AI.MIT.EDU
Cc: will@fog.cs.uoregon.edu
In-Reply-To: Chris Hanson's message of Tue, 20 Jun 89 19:44:57 edt <8906202344.AA04669@ZURICH.AI.MIT.EDU>
Subject: [will@cs.uoregon.edu: LIST-REF, LIST-TAIL]
Date: Tue, 20 Jun 89 19:44:57 edt
From: cph@ZURICH.AI.MIT.EDU (Chris Hanson)
Chris, can you provide this information? I don't remember precisely
what happened. All I know is that the editors recommended dropping
these procedures along with quite a few others, and at the meeting it
was voted to keep these two.
Date: Tue, 20 Jun 89 16:24:24 PDT
From: will@cs.uoregon.edu
To: cph@zurich.ai.mit.edu
Subject: LIST-REF, LIST-TAIL
Cc: rrrs-authors@zurich.ai.mit.edu
Chris, I think it would help the authors if you could explain why the
P1178 group feels that LIST-REF and LIST-TAIL need to be in the IEEE
standard. Right now the only thing we've got to go on is the fact that
P1178 has requested that they be made essential. As an editor of R4RS,
I don't feel comfortable making that change (in the face of a contrary
decision at Snowbird and an objection recently registered on rrrs-authors)
without some kind of technical rationale.
Peace, Will
You included all the info that I have, and all that I think is
relivant, in your recent note to the notesfile. There were no
technical arguments and don't need to be. The recommendation was
based on a feeling that LIST-REF and LIST-TAIL were sufficiently
important that they deserved to be standard, and they won't be as
efficient in some implementations if they aren't primitive. I expect
most people share my ambivalence on this issue. I think our
suggestion was a reasonable one, but if the rrrs-authors don't go for
it, then they win and we should move on to more important things.
∂22-Jun-89 1913 @mc.lcs.mit.edu:Pavel.pa@xerox.com Responses to a month of mail
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 22 Jun 89 19:12:59 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12567;
22 Jun 89 22:04 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Jun 89 22:02:06 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa28588; 22 Jun 89 21:56 EDT
Received: from Salvador.ms by ArpaGateway.ms ; 22 JUN 89 18:56:21 PDT
Date: Thu, 22 Jun 89 18:58:58 PDT
From: Pavel.pa@xerox.com
Subject: Responses to a month of mail
In-reply-to: <8905260106.AA18779@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Cc: Pavel.pa@xerox.com
Message-ID: <890622-185621-2108@Xerox>
Boy, I leave for a simple four-week vacation and no sooner do I get out of
the country but the various Scheme lists come to glorious life, full of
ideas and controversy. I have some comments on several things that have
been said over the past month.
=======
Date: Thu, 25 May 89 18:06:49 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Subject: planned changes to R3.95RS
Sections 2.1 (Identifiers), 2.3 (Other notations), and 7.1.1 (Lexical
structure). Add ... as a new peculiar identifier.
I would like to request that some character (preferably either period or
colon) be set aside for use in those implementations experimenting with
module facilities. In Scheme Xerox, we would like to have a notation for
``structured names'', in which the name of an ``interface'' is paired with
the name of an item in that interface. Mesa and Modula use the notation
``Foo.Bar'', CLU uses ``foo$bar'', and Common Lisp uses ``foo:bar'' and
``foo::bar''. Note that, for compatibility, the delimiter character canot
also be legal in identifiers. With the current list of special alphabetic
characters (after the acceptance of ``@'' in the list), my options are the
following:
# \ | [ ] { } , ' `
The last three of these (and the first, to a lesser extent) are not
acceptable because the possibility of an unnoticed typo is too great (when
an stray space appears before the delimiter). The brackets and braces
would look silly if they were unbalanced and are too cumbersome otherwise.
Backslash and vertical-bar look too much like escape characters (and are
such in Common Lisp).
The least unacceptable one is ``#''. I suppose that I could live with it,
but I'd sure prefer either period or colon. I'd therefore like to request
one of the following, listed in decreasing order of my preference:
1 - Remove period from the list of special subsequents (but leave ``...''
on the list of peculiar identifiers). Period is already somewhat special
because of its use in the syntax of pairs and improper lists; this and its
use in other languages for structured names, makes it the best candidate,
in my opinion.
2 - Remove colon from the list of special initials. The use of colon in
the Common Lisp (and Zetalisp) package systems is quite analagous to
structured names; there is thus significant precedence for the use of that
character in a Lisp-like language.
3 - Do nothing. Sigh.
Whichever of these is accepted, though, I'd like the report to state a
commitment to keep either the period, colon, or hash character (as
appropriate) out of identifiers in the future, specifically to allow
compatible experimentation with structured names in module systems.
=======
Date: Sun, 28 May 89 15:48:26 -0700
From: "Jonathan S. Shapiro" <shap@polya.stanford.edu>
Subject: Requested changes to R4RS
If the LOAD routine is
required to use READ, I could contemplate something like:
(define (myload file)
(let ((standard-read read))
(set! read myread)
(load file)
(set! read standard-read)))
The possibility of changing the value of a variable in the initial
environment, such as READ here, has always bothered me a great deal. In
long-lived, single address space systems, like the Lisp Machine or Cedar,
the normal mode of operation involves simultaneously running many
``programs'', usually written by different people. Changing the meaning of
one of the language primitives is very likely to have a negative impact on
the robustness of the overall system.
In addition, aside from the (also distressing) idea above, that one should
customize the behaviour of a primitive by (presumably temporarily) changing
the meaning of some other primitive, there seems to be no good reason ever
to side-effect the initial environment.
I would therefore like to request that R4RS state that it is an error to
assign to (or redefine) any of the variables defined in the report. In
particular, in Scheme Xerox, we intend to signal that error at compile-time
and would like this behaviour not to violate the specification. Please
note that this doesn't rule out the possibility of certain debugging tools
making such assignments, they just can't appear in programs.
=======
Date: Fri, 2 Jun 89 16:00:32 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Subject: Re: [ramsdell: truth of (), etc...]
<BODY> --> (define <I> <EXP>) ... <SEQUENCE> ==>
((lambda (<I> ...)
(set! <I> <EXP>)
...
<SEQUENCE>)
<UNDEFINED> ...)
(In other words, the proposal is to require that internal definitions
be
evaluated from left to right, with each succeeding definition allowed
to
use variables defined before it.)
I certainly don't want to exchange the LETREC semantics for this LET* one.
One of my most common uses for internal definitions is local recursive
procedures.
I'd like to request that the syntax and semantics of bodies and programs be
identical, but not quite like either one in R3RS. Let the syntax be
<program> ::= { <expression> | <definition> | (begin <program>) }*
<definition> ::= (define <variable> <expression>)
| (define (<variable> <def formals>) <body>)
<body> ::= <program>
so definitions and expressions can be freely mixed, both at ``top level''
and internally. Also, BEGINs at top level need not consist entirely of
definitions or entirely of expressions, as in R3.95RS. The semantics is as
follows:
-- (begin <program>) is entirely equivalent to <program> .
-- programs comprising only expressions and definitions have the same
meaning as given in the formal semantics in R3.95RS; that is, bindings are
established for all defined variables giving them unspecified values after
which the program is evaluated in sequence, treating definitions as if they
were assignments.
This is the most uniform, consistent, and useful way I can see to resolve
the difference in semantics between internal and external definitions.
Will says:
For what it's worth, here are the two reasons that I prefer the
existing
semantics:
1. I find that it is easier to understand code when I can assume
that
the order of definitions doesn't matter. That way I can read the
definitions in any order. This is a special case of the general
principle that a more declarative semantics makes programs easier
to understand.
2. (This reason is pretty weak.) For the compiler writer, I think
the
freedom to rearrange definitions makes closure analysis a little
simpler when procedure definitions are mixed with definitions of
variables containing non-procedure values.
Reason 1 would seem to apply equally well to the top level of Scheme
programs, but I suspect that Will would not be in favor of giving the
LETREC semantics to those definitions (it would make it very difficult to
get anything done). I agree with Will on the strength of the second
reason.
=======
While I'm at it, I'd like to hear from others about why we allow
(define (foo a) 17)
==> (define foo (lambda (a) 17))
but not the obvious extension of this (OK in C-Scheme, I think):
(define ((foo a) b) (+ a b))
==> (define foo
(lambda (a)
(lambda (b)
(+ a b))))
I implemented this for Cedar Scheme and have found it quite useful. I
can't see any reason to go halfway here, only allowing this abbreviation
one level deep.
=======
Just to summarize, I've made four proposals for R4RS in this message:
* Change the rules for the formation of identifiers,
* Outlaw assignments to built-in variables,
* Make the semantics of internal and external definitions identical, and
* Extend the syntax of procedure definitions.
Pavel
∂22-Jun-89 2146 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #144
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 22 Jun 89 21:46:23 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20747;
23 Jun 89 0:40 EDT
Date: 23 JUN 89 00:10:45 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #144
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8906230040.aa20747@mintaka.lcs.mit.edu>
Scheme Digest #144 23 JUN 89 00:10:45 EDT
Today's Topics:
"unspecified" and SET!
----------------------------------------------------------------------
Date: 22 Jun 89 03:27:48 GMT
From: John Gateley <apple!sun-barr!texsun!pollux!ti-csl!m2!gateley@rutgers.edu>
Subject: Re: "unspecified" and SET!
Message-Id: <81872@ti-csl.csc.ti.com>
In article <2281@ubc-cs.UUCP> manis@grads.cs.ubc.ca (Vincent Manis) writes:
>Going to the trouble to develop a calculus of unspecified values
>strikes me as almost as silly as some of the things I did when I was
>involved in writing an Algol 68 compiler.
...
>____________ Vincent Manis | manis@cs.ubc.ca
...
Do you mean Matthias Felleisen's calculus for Scheme? It is neither a
calculus of unspecified values nor silly. It is a better theoretical
basis for Scheme than the lambda value calculus: it includes both
set! style side effects and continuations in its equations.
John
gateley@m2.csc.ti.com
------------------------------
End of Scheme Digest
********************
∂23-Jun-89 0934 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu Responses to a month of mail
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 23 Jun 89 09:34:11 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13401;
23 Jun 89 12:26 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 23 Jun 89 12:22:56 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa23571;
23 Jun 89 12:15 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA29108; Fri, 23 Jun 89 09:15:07 PDT
Date: Fri, 23 Jun 89 09:15:07 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906231615.AA29108@sesame.Stanford.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu, Pavel.pa@xerox.com
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 22 Jun 89 18:58:58 PDT <890622-185621-2108@Xerox>
Subject: Responses to a month of mail
Date: Thu, 22 Jun 89 18:58:58 PDT
From: Pavel.pa@xerox.com
Date: Sun, 28 May 89 15:48:26 -0700
From: "Jonathan S. Shapiro" <shap@polya.stanford.edu>
Subject: Requested changes to R4RS
If the LOAD routine is
required to use READ, I could contemplate something like:
(define (myload file)
(let ((standard-read read))
(set! read myread)
(load file)
(set! read standard-read)))
The possibility of changing the value of a variable in the initial
environment, such as READ here, has always bothered me a great deal. In
long-lived, single address space systems, like the Lisp Machine or Cedar,
the normal mode of operation involves simultaneously running many
``programs'', usually written by different people. Changing the meaning of
one of the language primitives is very likely to have a negative impact on
the robustness of the overall system.
In addition, aside from the (also distressing) idea above, that one should
customize the behaviour of a primitive by (presumably temporarily) changing
the meaning of some other primitive, there seems to be no good reason ever
to side-effect the initial environment.
I would therefore like to request that R4RS state that it is an error to
assign to (or redefine) any of the variables defined in the report. In
particular, in Scheme Xerox, we intend to signal that error at compile-time
and would like this behaviour not to violate the specification. Please
note that this doesn't rule out the possibility of certain debugging tools
making such assignments, they just can't appear in programs.
The operative phrase when changing a built-in definition is obviously "caveat
emptor". However, I do not believe in facist (-: languages. I would aceed to
placing a warning about rebinding primitives in R*RS, but feel quite strongly
that prohibiting such is a bad idea.
Morry Katz
katz@polya.stanford.edu
∂23-Jun-89 1328 @mc.lcs.mit.edu,@mojave.stanford.edu:shap@sid.stanford.edu Responses to a month of mail
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 23 Jun 89 13:27:59 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02892;
23 Jun 89 16:25 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 23 Jun 89 16:21:07 EDT
Received: from Mojave.Stanford.EDU by mintaka.lcs.mit.edu id aa02724;
23 Jun 89 16:15 EDT
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
id AA27573; Fri, 23 Jun 89 13:13:07 PDT
Message-Id: <8906232013.AA27573@mojave.Stanford.EDU>
Received: by sid; Fri, 23 Jun 89 13:15:34 pdt
Date: Fri, 23 Jun 89 13:15:34 pdt
From: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 22 Jun 89 18:58:58 PDT <890622-185621-2108@Xerox>
Subject: Responses to a month of mail
Regarding reserving a character for modules: I am torn. On the one
hand, it is a good idea for experimental purposes. On the other hand,
the fact that there is no general agreement on modules means that such
things won't port from one scheme to another, and I am reluctant to
see such a thing introduced into the language just when there is an
attempt to standardize - someone will subsequently decide to
standardize modules, which we don't yet have any concensus on.
Further, it strikes me that from the standpoint of the scheme system
I want
foo:bar
to be a symbol in the same way that
bar
is a symbol - the differentiation in interpretation, if any, should
happen in string-symbol (or its equivalent) in the reader.
The point is: I would buy that it would be valuable to state somewhere
in the symbol character stuff that some character [I like ':' - no
reason to be gratuitously different from existing LISP usage in the
absence of technical arguments favoring one character over another] is
intended to be used as a module separator in the future, and that
program authors are encouraged to write their programs accordingly,
but I do not think that it is necessary at this time to raise this to
the level of syntax, nor do I want to see the character removed from
the list of legal symbol name characters until their exists a compelling
rationale for doing so.
Proposal: add such a statement to R4RS.
on
∂26-Jun-89 0648 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #145
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 26 Jun 89 06:48:15 PDT
Received: by mintaka.lcs.mit.edu id ae25553; 26 Jun 89 9:20 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id ab06579;
26 Jun 89 0:39 EDT
Date: 26 JUN 89 00:07:06 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #145
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8906260039.ab06579@mintaka.lcs.mit.edu>
Scheme Digest #145 26 JUN 89 00:07:06 EDT
Today's Topics:
"unspecified" and SET!
"unspecified" and SET!
----------------------------------------------------------------------
Date: 23 Jun 89 02:01:05 GMT
From: Vincent Manis <att!alberta!ubc-cs!grads.cs.ubc.ca!manis@bloom-beacon.mit.edu>
Subject: Re: "unspecified" and SET!
Message-Id: <2322@ubc-cs.UUCP>
In article <81872@ti-csl.csc.ti.com> gateley@m2.UUCP (John Gateley) writes:
>Do you mean Matthias Felleisen's calculus for Scheme? It is neither a
>calculus of unspecified values nor silly. It is a better theoretical
>basis for Scheme than the lambda value calculus: it includes both
>set! style side effects and continuations in its equations.
To clarify, let me say emphatically that I *don't* mean Felleisen's
calculus. As John says, Felleisen's work is not at all silly. I was
instead referring to the proposals for #!unspecified, which, is either
the same as `bottom' in denotational semantics or it is not. In the
former case, #!unspecified should be returned, also, in both a
division by 0 and a non-terminating recursion. In the latter case,
#!unspecified is somewhat pointless (set! could just as easily return
`()), unless one has some reason for distinguishing the two.
While I do not care for William of Ockham's metaphysics, there is much
to say for his Razor.
____________ Vincent Manis | manis@cs.ubc.ca
___ \ _____ The Invisible City of Kitezh | manis@cs.ubc.cdn
____ \ ____ Department of Computer Science | manis%cs.ubc@relay.cs.net
___ /\ ___ University of British Columbia | uunet!ubc-cs!manis
__ / \ __ Vancouver, BC, Canada V6T 1W5 | (604) 228-2394
_ / __ \ _ "Theoretical computer science helps me convince people that
____________ my indecisiveness is really Nondeterminism, which sounds like
a much more positive characteristic." -- a student
------------------------------
Date: 25 Jun 89 22:17:45 GMT
From: Dorai Sitaram <titan!dorai@rice.edu>
Subject: Re: "unspecified" and SET!
Message-Id: <4011@kalliope.rice.edu>
In article <2281@ubc-cs.UUCP> manis@grads.cs.ubc.ca (Vincent Manis) writes:
>Going to the trouble to develop a calculus of unspecified values
>strikes me as almost as silly as some of the things I did when I was
>involved in writing an Algol 68 compiler.
If this is in response to my posting(s) entitled "unspecified and
set!" (and I'm not sure it is -- Vincent doesn't say), I request
permission to shriek, "No! This is not what I meant!" ;-)
I was drawing attention to side-effecting constructs in the literature
(that they appeared in a calculus-definition is of secondary
importance) that give all the "power" of current Schemes WITHOUT
having to mess with (returning) unspecified values at all. I do, of
course, concur with Vincent that having an unspecified object like
#!unspecified is close to being the all-time great oxymoron of our
troubled times (though he might not use the selfsame words ;-]).
Second, the comparison that Vincent draws between "(#!)unspecified"
and "bottom" is not correct. "Bottom" stands for divergence
(non-termination) and occasionally, errors; "(#!)unspecified" is a
stopgap value concocted to stand for a meaningless value returned in a
TERMINATING computation.
--dorai
-------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
-------------------------------------------------------------------------------
------------------------------
End of Scheme Digest
********************
∂26-Jun-89 2154 @mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Responses to a month of mail
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 26 Jun 89 21:54:00 PDT
Received: by mintaka.lcs.mit.edu id ag14232; 27 Jun 89 0:28 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12978;
26 Jun 89 22:17 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 26 Jun 89 22:11:59 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 228955; Mon 26-Jun-89 22:11:31 EDT
Date: Mon, 26 Jun 89 22:11 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Subject: Responses to a month of mail
To: Pavel.pa@xerox.com
cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <890622-185621-2108@Xerox>
Message-ID: <19890627021113.8.ALAN@PIGPEN.AI.MIT.EDU>
Date: Thu, 22 Jun 89 18:58:58 PDT
From: Pavel.pa@xerox.com
Date: Fri, 2 Jun 89 16:00:32 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
<BODY> --> (define <I> <EXP>) ... <SEQUENCE> ==>
((lambda (<I> ...)
(set! <I> <EXP>)
...
<SEQUENCE>)
<UNDEFINED> ...)
(In other words, the proposal is to require that internal
definitions be evaluated from left to right, with each succeeding
definition allowed to use variables defined before it.)
I certainly don't want to exchange the LETREC semantics for this LET*
one. One of my most common uses for internal definitions is local
recursive procedures.
This remark confuses me. I don't see anything LET* like about what Will
proposed here. This looks to me to be exactly what you want if you want
internal definitions to behave like top level definitions. It works just
fine to define local recursive procedures. If it was LET*-like,
definitions wouldn't be able to refer to later definitions.
∂26-Jun-89 2155 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #146
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 26 Jun 89 21:55:12 PDT
Received: by mintaka.lcs.mit.edu id ai14240; 27 Jun 89 0:29 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13965;
27 Jun 89 0:17 EDT
Date: 27 JUN 89 00:07:05 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #146
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8906270017.aa13965@mintaka.lcs.mit.edu>
Scheme Digest #146 27 JUN 89 00:07:05 EDT
Today's Topics:
Scheme Digest #145
----------------------------------------------------------------------
From: Chet Murthy <murthy@cs.cornell.edu>
Message-Id: <8906261457.AA02518@lakshmi.cs.cornell.edu>
Subject: Re: Scheme Digest #145
Date: Mon, 26 Jun 89 10:57:57 -0400
Please remove me from the Scheme mailing list.
My addresses are:
murthy@cs.cornell.edu
murthy@svax.cs.cornell.edu
Thanks,
--chet--
------------------------------
End of Scheme Digest
********************
∂27-Jun-89 1311 @mc.lcs.mit.edu:Pavel.pa@xerox.com Responses to responses to responses
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 27 Jun 89 13:11:11 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22689;
27 Jun 89 15:55 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jun 89 15:31:23 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa22336; 27 Jun 89 15:27 EDT
Received: from Salvador.ms by ArpaGateway.ms ; 27 JUN 89 12:12:18 PDT
Date: Tue, 27 Jun 89 12:20:31 PDT
From: Pavel.pa@xerox.com
Subject: Responses to responses to responses
In-reply-to: <19890627021113.8.ALAN@PIGPEN.AI.MIT.EDU>
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890627-121218-3423@Xerox>
Alan Bawden is quite right; a thinko made me misread David Bartley's
expansion of a body and think that it was a LET*-style expansion. Sigh.
=====
Morry Katz says, ``I would aceed to placing a warning about rebinding
primitives in R*RS, but feel quite strongly that prohibiting such is a bad
idea.''
This is precisely what I'm asking for. A warning would have to say
something like, ``If you redefine a primitive, you could lose horribly.''
I think we have a simple way of saying that, namely, ``It is an error to
redefine a primitive.'' The way you'll lose horribly in Scheme Xerox is
that your program won't compile. I'm not asking R4RS to prohibit
redefinition, I'm simply asking it to let me do so in my own
implementation.
I forgot to mention in my previous message the other, fairly obvious
problem with allowing redefinition. Just as a human program reader cannot
be sure of the semantics of any (even top-level) program fragment (since
the remainder of the program might redefine one or more of the primitives),
neither can the compiler. Thus, without guaranteed knowledge of the
entirety of the program, the compiler cannot both preserve the semantics of
the program and code certain primitives inline.
Contrary to Morry's semi-facetious claim that prohibiting redefinition is
``fascist'', it is the only way that a compiler can answer the twin desires
of its customers for efficiency and correctness.
=====
Jonathan Shapiro says, ``I would buy that it would be valuable to state
somewhere in the symbol character stuff that some character ... is intended
to be used as a module separator in the future, and that
program authors are encouraged to write their programs accordingly, but I
do not think that it is necessary at this time to raise this to the level
of syntax ...''
Unfortunately, I don't believe that this is sufficient. The only way
program authors can write their programs accordingly is to avoid using the
separator character at all. Otherwise, their code will not run in
implementations that use structured names, since it will very likely refer
to undefined module/interface names.
Jonathans Shapiro and Rees (the latter in private mail) recommended that
the actual sequence of characters in an identifier's name have some
semantic significance, apart from giving the identity of the identifier.
Shapiro wanted names with colons in them to behave differently than names
without colons; Rees suggested a notion somewhat like ``conc-names'' in
Common Lisp's DEFSTRUCT facility, whereby the programmer could, in a
limited scope, give special semantics to all names with a particular
prefix. These ideas feel very wrong to me, a violation of the
alpha-conversion rule. The sequence of characters in a name shouldn't have
any semantics aside from their identity.
=======
My four proposals (see my previous message) still stand; does anyone else
have any comments on them?
Pavel
∂27-Jun-89 1419 @MC.lcs.mit.edu:jinx@ZURICH.ai.mit.edu Responses to responses to responses
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 27 Jun 89 14:19:22 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28271;
27 Jun 89 17:12 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jun 89 17:09:07 EDT
Received: from [18.43.0.171] by mintaka.lcs.mit.edu id aa08496;
27 Jun 89 17:04 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Tue, 27 Jun 89 17:00:26 edt
Date: Tue, 27 Jun 89 17:00:26 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8906272100.AA09821@ZURICH.AI.MIT.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@MC.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Tue, 27 Jun 89 12:20:31 PDT <890627-121218-3423@Xerox>
Subject: Responses to responses to responses
Morry Katz says, ``I would aceed to placing a warning about rebinding
primitives in R*RS, but feel quite strongly that prohibiting such is a bad
idea.''
This is precisely what I'm asking for. A warning would have to say
something like, ``If you redefine a primitive, you could lose horribly.''
I think we have a simple way of saying that, namely, ``It is an error to
redefine a primitive.'' The way you'll lose horribly in Scheme Xerox is
that your program won't compile. I'm not asking R4RS to prohibit
redefinition, I'm simply asking it to let me do so in my own
implementation.
I think you misunderstand Morry, but just in case, I'll state my
position, which I believe coincides with his and was the consensus of
most implementors a while ago.
An implementation that does not allow assignment of the initial
variables (including those bound to procedures) in an RnRs environment
is in ERROR. Yes, I mean that. I feel very strongly that the user
takes precedence over the system.
It is acceptable, however, for an implementation to default to
"benchmark" mode, as long as the following two conditions are met:
1) There is a way to take it out of benchmark mode.
2) Appropriate warnings about redefinition/warning are given when the
implementation is in benchmark mode and an assignment/redefinition is
"attempted".
Contrary to Morry's semi-facetious claim that prohibiting redefinition is
``fascist'', it is the only way that a compiler can answer the twin desires
of its customers for efficiency and correctness.
I don't think you are right. I think a compiler can answer both,
after providing declarations. We are talking here about what
the behaviour should be in their absence. You may be right that
utmost efficiency cannot be obtained without declarations, but that is
a small price to pay.
∂27-Jun-89 2001 @MC.lcs.mit.edu,@ZERMATT.lcs.mit.edu:SCHREQ@MC.lcs.mit.edu testing
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 27 Jun 89 20:01:23 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28060;
27 Jun 89 22:55 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 27 Jun 89 22:52:34 EDT
Received: from MICKEY-MOUSE.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 269280; Tue 27-Jun-89 22:52:30 EDT
Date: Tue, 27 Jun 89 22:52 EDT
From: Scheme Requestee <SCHREQ@MC.lcs.mit.edu>
Subject: testing
To: rrrs-authors@MC.lcs.mit.edu
Message-ID: <"19890628025210.2.schreq@MC"@MICKEY-MOUSE.LCS.MIT.EDU>
Testing the list.
∂27-Jun-89 2147 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #147
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 27 Jun 89 21:47:18 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa29209;
28 Jun 89 0:37 EDT
Date: 28 JUN 89 00:07:08 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #147
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8906280037.aa29209@mintaka.lcs.mit.edu>
Scheme Digest #147 28 JUN 89 00:07:08 EDT
Today's Topics:
Looking for R*RS and XScheme source by ftp
----------------------------------------------------------------------
Date: 27 Jun 89 17:16:32 GMT
From: John Lacey <lacey@tcgould.tn.cornell.edu>
Subject: Looking for R*RS and XScheme source by ftp
Message-Id: <8271@batcomputer.tn.cornell.edu>
I'm looking for the Revised Report, as well as the
source to XScheme (by David Betz), preferably by ftp. Actually,
if anyone knows of another free Scheme implementation, I would like
to hear about it.
I'll take the report in any form I can get it, but I would
prefer a [La]TeX format.
--
John Lacey | Internet: lacey@tcgould.tn.cornell.edu
running unattached | BITnet: lacey@crnlthry
| UUCP: cornell!batcomputer!lacey
------------------------------
End of Scheme Digest
********************
∂28-Jun-89 0847 @mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu Responses to a month of mail
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 28 Jun 89 08:47:03 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24888;
28 Jun 89 11:17 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 10:59:21 EDT
Received: from [18.43.0.171] by mintaka.lcs.mit.edu id aa24526;
28 Jun 89 10:58 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Wed, 28 Jun 89 10:55:21 edt
Date: Wed, 28 Jun 89 10:55:21 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8906281455.AA27360@ZURICH.AI.MIT.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 22 Jun 89 18:58:58 PDT <890622-185621-2108@Xerox>
Subject: Responses to a month of mail
Because of mailer problems on our file server (zurich), I did not read
your four point proposal until now. Here are my thoughts:
* Change the rules for the formation of identifiers,
I don't think this is warranted. I think that lexical level
conventions for module references are a bad idea.
* Outlaw assignments to built-in variables,
Definitely not. Implementations should be built in such a way that
assignment/definition in an RnRs environment does not affect the
integrity of the implementation. This should impose constraints on
the implementor, not the user. Note that single address space does
not imply a flat namespace, which Lisp Machines effectively have.
I have "ideological" reasons against this proposal, and pragmatic ones
as well.
The main ideological reason is that the system/implementation is a
tool for the user, and as such it should accomodate the wishes of the
user, not viceversa. Thus if a user wants to call CAR something he
writes/uses (in a Church pair implmentation, for example), he should
be allowed to do so.
The pragmatic reason may concern you more. Presumably you would like
implementations to be able to add new primitives to the language
described in the report. Given that the semantics of any programs
using them might be compromised in the same way that it would be when
using a "standard" primitive, you would disallow assignment and
redefinition of implementation-specific primitives as well. This
implies that portability can only be achieved by using obscure names
(ie G00034), since any "reasonable" name is potentially reserved by
some implementation.
For example: I may write my own structure facility (ignoring the
problem with portable macros, for the time being), and decide to use
my own even if the implementation provides a similar facility. I
don't want to have to change all uses of defstruct or define-structure
whenever I port to a new implementation, but your proposal might force
me to. An equivalent problem arises with the names of procedures.
* Make the semantics of internal and external definitions identical, and
I agree that they should be the same in principle. My personal
preference would be for making top level definitions behave like the
current letrec, ie. order independent. This is, unfortunately, too
radical to be accepted by most people. I prefer the current letrec
semantics to the proposed "sequential" semantics.
* Extend the syntax of procedure definitions.
MIT Scheme has had this for a while, but we've decided to back out of
it. The problem is that it does not combine well (in terms of
readability) with the following syntax for types, which we currently
believe to be a better use for parentheses in lambda lists:
(lambda ((x integer?) (y pair?))
<some code>)
∂28-Jun-89 0940 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu Responses to responses to responses
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 28 Jun 89 09:40:32 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25670;
28 Jun 89 12:13 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 11:51:01 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa25200;
28 Jun 89 11:48 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA21003; Wed, 28 Jun 89 08:47:46 PDT
Date: Wed, 28 Jun 89 08:47:46 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906281547.AA21003@sesame.Stanford.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Tue, 27 Jun 89 12:20:31 PDT <890627-121218-3423@Xerox>
Subject: Responses to responses to responses
Date: Tue, 27 Jun 89 12:20:31 PDT
From: Pavel.pa@xerox.com
Morry Katz says, ``I would aceed to placing a warning about rebinding
primitives in R*RS, but feel quite strongly that prohibiting such is a bad
idea.''
This is precisely what I'm asking for. A warning would have to say
something like, ``If you redefine a primitive, you could lose horribly.''
I think we have a simple way of saying that, namely, ``It is an error to
redefine a primitive.'' The way you'll lose horribly in Scheme Xerox is
that your program won't compile. I'm not asking R4RS to prohibit
redefinition, I'm simply asking it to let me do so in my own
implementation.
You have very carefully perverted what I have said to suit your own fancy. You
did not request that an implementation be allowed to prohibit redefinition of
the primitives, but stated that you wanted redefinition of a primitive to be an
error. Your original request read as follows:
"I would therefore like to request that R4RS state that it is an error to
assign to (or redefine) any of the variables defined in the report. In
particular, in Scheme Xerox, we intend to signal that error at compile-time
and would like this behavior not to violate the specification. Please note
that this doesn't rule out the possibility of certain debugging tools making
such assignments, they just can't appear in programs."
If you would like to propose something that allows your system to consider
redefinition an error but does not require my system to do such, I might be
willing to consider it.
I forgot to mention in my previous message the other, fairly obvious
problem with allowing redefinition. Just as a human program reader cannot
be sure of the semantics of any (even top-level) program fragment (since
the remainder of the program might redefine one or more of the primitives),
neither can the compiler. Thus, without guaranteed knowledge of the
entirety of the program, the compiler cannot both preserve the semantics of
the program and code certain primitives inline.
Contrary to Morry's semi-facetious claim that prohibiting redefinition is
``fascist'', it is the only way that a compiler can answer the twin desires
of its customers for efficiency and correctness.
Nearly everyones compiler currently allows a compiler directive to the effect
that primitives should be considered immutable and therefore inlineable. This
has been done for the obvious efficiency reasons and does not require that the
language specification be altered to always prohibit modifying primitives.
Morry Katz
katz@polya.stanford.edu
∂28-Jun-89 1125 @mc.lcs.mit.edu,@ZURICH.ai.mit.edu:mkatz@sesame.stanford.edu Declare proposal
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 28 Jun 89 11:25:49 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16802;
28 Jun 89 13:08 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 12:22:43 EDT
Received: from ZURICH.AI.MIT.EDU by mintaka.lcs.mit.edu id aa25847;
28 Jun 89 12:21 EDT
Return-Path: <mkatz@sesame.Stanford.EDU>
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by ZURICH.AI.MIT.EDU; Wed, 28 Jun 89 12:18:49 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA21063; Wed, 28 Jun 89 09:02:14 PDT
Date: Wed, 28 Jun 89 09:02:14 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906281602.AA21063@sesame.Stanford.EDU>
To: rrrs-authors@ZURICH.ai.mit.edu
Subject: Declare proposal
I would like to propose that we make DECLARE a special form to be used for
compiler directives. We do not have to standardize the complete format of
declare, at this time; but, I would like to set aside the name. This would
allow greater portability of programs as friendly systems could merely ignore
declarations which they don't understand and give some type of warning.
Morry Katz
katz@polya.stanford.edu
∂28-Jun-89 1345 @mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@bloom.la.tek.com Re: A month of mail...
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 28 Jun 89 13:45:30 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09897;
28 Jun 89 16:15 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 15:21:07 EDT
Received: from RELAY.CS.NET by mintaka.lcs.mit.edu id aa15465;
28 Jun 89 15:19 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa19941; 28 Jun 89 15:06 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA00388; Wed, 28 Jun 89 12:07:15 PDT
Received: by dadla.LA.TEK.COM (5.51/6.24)
id AA26696; Wed, 28 Jun 89 12:00:57 PDT
Received: from localhost.ARPA by bloom.LA.TEK.COM (1.2/6.24)
id AA11945; Wed, 28 Jun 89 12:05:48 pdt
Message-Id: <8906281905.AA11945@bloom.LA.TEK.COM>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: Re: A month of mail...
Date: Wed, 28 Jun 89 12:05:43 PDT
From: kend@bloom.la.tek.com
$0.02
>> * Change the rules for the formation of identifiers,
I also feel that strange naming conventions are not warrented for module
experimentation. Modules seen as compile-time early-binding, first-class
environments [(*value module-1 'foo)], etc. do not require this.
>> * Outlaw assignments to built-in variables,
[ASIDE: I prefer binding to side effects for specialization of routines.
John should be asking for more general tools:
"(define myload (make-load my-reader))"
].
You probably do want an implementation environment in which you can depend
on names to mean certain things [(define-constant car %primitive-car)], but
a user environment should be provided in which the user can rebind car
[perhaps with a warning]. As environments are outside of the language
definition, *requiring* that the user environment have immutable names
violates both the spirit and the practice of the language.
>> * Make the semantics of internal and external definitions identical, and
I like the internal semantics and would like to change the name of the
special form used in interactive loops from "define" to something else (e.g.
"defun"). The top-level-environment is an artifact of an interactive
system. We could make a naming distinction between uses/behaviors, rather
than changing uses because of a name alias.
>> * Extend the syntax of procedure definitions.
How is this going to affect other potential extensions [e.g. Dybvig & Heib's
variable-arity procedural interface]? [I don't strongly oppose this].
{After all, how much is $.02 worth?}
-Ken kend@mrloog.LA.TEK.COM
∂28-Jun-89 2147 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #148
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 28 Jun 89 21:47:25 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17812;
29 Jun 89 0:36 EDT
Date: 29 JUN 89 00:07:25 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #148
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8906290036.aa17812@mintaka.lcs.mit.edu>
Scheme Digest #148 29 JUN 89 00:07:25 EDT
Today's Topics:
Looking for R*RS and XScheme source by ftp
----------------------------------------------------------------------
Date: 28 Jun 89 10:54:44 GMT
From: Oliver Laumann <mcvax!unido!tub!net@uunet.uu.net>
Subject: Re: Looking for R*RS and XScheme source by ftp
Message-Id: <867@tub.UUCP>
In article <8271@batcomputer.tn.cornell.edu> lacey@tcgould.tn.cornell.edu (John Lacey) writes:
> if anyone knows of another free Scheme implementation, I would like
> to hear about it.
I'm going to send the sources of a Scheme interpreter to comp.sources.unix
next week. You can expect it to be posted by Rich Salz in about 4 weeks.
The interpreter is R↑3RS compatible, includes interfaces to the Xlib,
to Xt, and to the Athena and HP widget libraries of X11R3. It was
written to be used as an general extension language interpreter (to be
linked into an application); it is also useful as a stand-alone
implementation of Scheme.
Regards,
--
Oliver Laumann net@TUB.BITNET net@tub.UUCP
------------------------------
End of Scheme Digest
********************
∂28-Jun-89 2257 @mc.lcs.mit.edu:shap@sid.stanford.edu A month of mail...
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 28 Jun 89 22:57:08 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28724;
29 Jun 89 1:26 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 01:05:06 EDT
Received: from [36.22.0.120] by mintaka.lcs.mit.edu id aa16361;
29 Jun 89 1:03 EDT
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
id AA06777; Wed, 28 Jun 89 22:00:25 PDT
Message-Id: <8906290500.AA06777@mojave.Stanford.EDU>
Received: by sid; Wed, 28 Jun 89 22:03:02 pdt
Date: Wed, 28 Jun 89 22:03:02 pdt
From: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
To: kend@bloom.la.tek.com
Cc: Pavel.pa@xerox.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: kend@bloom.la.tek.com's message of Wed, 28 Jun 89 12:05:43 PDT <8906281905.AA11945@bloom.LA.TEK.COM>
Subject: A month of mail...
Ken's comment sort of blew past a point I think is interesting. We
might be able to satisfy both desires - mutability and immutability -
by reserving some suitably small part of the namespace for system
primitives, e.g. identifiers with names whose leading substring is
"%primitive-"
Jon
∂29-Jun-89 0533 @mc.lcs.mit.edu,@mbunix.mitre.org:ramsdell@linus.mitre.org Make the semantics of internal and external definitions identical
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 29 Jun 89 05:33:47 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20691;
29 Jun 89 8:28 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 08:24:54 EDT
Received: from mbunix.mitre.org by mintaka.lcs.mit.edu id aa20553;
29 Jun 89 8:19 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA01030; Thu, 29 Jun 89 08:16:41 EDT
Posted-Date: Thu, 29 Jun 89 08:16:35 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA01374; Thu, 29 Jun 89 08:16:35 EDT
Date: Thu, 29 Jun 89 08:16:35 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8906291216.AA01374@huxley.mitre.org>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 22 Jun 89 18:58:58 PDT <890622-185621-2108@Xerox>
Subject: Make the semantics of internal and external definitions identical
Reply-To: ramsdell@mitre.org
From: Pavel.pa@xerox.com
I'd like to request that the syntax and semantics of bodies and programs be
identical, but not quite like either one in R3RS. ....
I just would like to note this is a more radical proposal than my
original proposal, and I curtainly support it.
This is the most uniform, consistent, and useful way I can see to resolve
the difference in semantics between internal and external definitions.
This is a better technical proposal than mine. However, if people
reject this idea, I hope they will still consider just changing the
semantics of internal definitions.
John
∂29-Jun-89 0956 @MC.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Responses to a month of mail
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 29 Jun 89 09:56:23 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18138;
29 Jun 89 12:51 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 29 Jun 89 12:48:29 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 230218; Thu 29-Jun-89 12:47:54 EDT
Date: Thu, 29 Jun 89 12:47 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Subject: Responses to a month of mail
To: jinx@ZURICH.ai.mit.edu, kend@bloom.la.tek.com
cc: Pavel.pa@xerox.com, rrrs-authors@MC.lcs.mit.edu
In-Reply-To: <8906281455.AA27360@ZURICH.AI.MIT.EDU>,
<8906281905.AA11945@bloom.LA.TEK.COM>
Message-ID: <19890629164733.2.ALAN@PIGPEN.AI.MIT.EDU>
Date: Wed, 28 Jun 89 10:55:21 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
* Change the rules for the formation of identifiers,
I don't think this is warranted. I think that lexical level
conventions for module references are a bad idea.
Date: Wed, 28 Jun 89 12:05:43 PDT
From: kend@bloom.la.tek.com
>> * Change the rules for the formation of identifiers,
I also feel that strange naming conventions are not warrented for module
experimentation. Modules seen as compile-time early-binding, first-class
environments [(*value module-1 'foo)], etc. do not require this.
I also think that using a special lexical syntax for module references is
probably a bad idea. But I don't agree that we should prevent others from
experimentation.
The proposal, as I recall it (I don't have Pavel's original message
anymore), is -not- to declare that ":" is used for module references. The
proposal is simply to remove ":" from the list of characters you can use in
a portable program. This leaves implementations free to do whatever they
want with ":". Some will experiment with using it for module references.
Others will treat it as an ordinary symbol constituent. Some may signal
an error. (Some may even use it to introduce a new kind of comment!)
No programmer would be forced to do anything except refrain from using ":"
in portable code. You already can't use "[" portably, because there is
disagreement about what it means. I could cause a lot of trouble by
insisting that we move "[" into the list of extended alphabetic characters,
but out of deference to people who have other opinions I am willing to
simply refrain from using "[". This seems to me to be an acceptable
compromise -- I am not greatly inconvenienced by it and others are made
much happier.
Of course I am aware that others may judge the tradeoff differently.
Indeed, if we always give in to people want to reserve characters for
special purposes, we will eventually have nothing left to name our symbols
with, so the line does have to be drawn somewhere. But this colon issue
keeps coming up over and over -- it seems that we will never be free of the
pressure to demote ":" to reserved status -- so in this case I think we
should yield to that pressure.
∂29-Jun-89 1254 @mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@bloom.la.tek.com Re: A month of mail...
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 29 Jun 89 12:54:48 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28183;
29 Jun 89 15:44 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 15:38:36 EDT
Received: from RELAY.CS.NET by mintaka.lcs.mit.edu id aa08078;
29 Jun 89 13:25 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa22273; 29 Jun 89 13:24 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA16418; Thu, 29 Jun 89 09:37:29 PDT
Received: by dadla.LA.TEK.COM (5.51/6.24)
id AA19249; Thu, 29 Jun 89 09:31:13 PDT
Received: from localhost.ARPA by bloom.LA.TEK.COM (1.2/6.24)
id AA12503; Thu, 29 Jun 89 09:36:02 pdt
Message-Id: <8906291636.AA12503@bloom.LA.TEK.COM>
To: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
Cc: Pavel.pa@xerox.com, rrrs-authors@mc.lcs.mit.edu
Subject: Re: A month of mail...
In-Reply-To: Your message of Wed, 28 Jun 89 22:03:02 -0700.
<8906290500.AA06777@mojave.Stanford.EDU>
Date: Thu, 29 Jun 89 09:35:58 PDT
From: kend@bloom.la.tek.com
> Ken's comment sort of blew past a point I think is interesting. We
> might be able to satisfy both desires - mutability and immutability -
> by reserving some suitably small part of the namespace for system
> primitives, e.g. identifiers with names whose leading substring is
> "%primitive-"
>
> Jon
Sorry to belabor the point, but...
If you use a *different* namespace for the implementation environment than
for the user environment, you do *not* have to make immutable any names in
the user environment. If a user has a function to allow him access to the
implementation environment, he can be sure he is getting at a particular
primitive [barring syntactic transformations--see discussion in the
Syntactic Closures paper in the last L&FP Conf.]. By giving out an access
function without giving a mutation function, the implementation environment
is immutable *from the user's viewpoint* without doing anything special
[although you may want to do so for other reasons].
...All this without reserving any part of the user visable namespace.
-Ken kend@mrloog.LA.TEK.COM
∂29-Jun-89 1434 @mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@bloom.la.tek.com Re: Responses to a month of mail
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 29 Jun 89 14:34:23 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22909;
29 Jun 89 17:30 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 17:27:00 EDT
Received: from RELAY.CS.NET by mintaka.lcs.mit.edu id aa22797;
29 Jun 89 17:24 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa28749; 29 Jun 89 17:20 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA27434; Thu, 29 Jun 89 14:22:23 PDT
Received: by dadla.LA.TEK.COM (5.51/6.24)
id AA26610; Thu, 29 Jun 89 14:16:07 PDT
Received: from localhost.ARPA by bloom.LA.TEK.COM (1.2/6.24)
id AA12833; Thu, 29 Jun 89 14:20:56 pdt
Message-Id: <8906292120.AA12833@bloom.LA.TEK.COM>
To: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Cc: jinx@ZURICH.ai.mit.edu, kend@bloom.la.tek.com, Pavel.pa@xerox.com,
rrrs-authors@mc.lcs.mit.edu
Subject: Re: Responses to a month of mail
In-Reply-To: Your message of Thu, 29 Jun 89 12:47:00 -0400.
<19890629164733.2.ALAN@PIGPEN.AI.MIT.EDU>
Date: Thu, 29 Jun 89 14:20:52 PDT
From: kend@bloom.la.tek.com
>> From: Alan Bawden <Alan@reagan.ai.mit.edu>
> ... so the line does have to be drawn somewhere. But this colon issue
> keeps coming up over and over -- it seems that we will never be free of the
> pressure to demote ":" to reserved status -- so in this case I think we
> should yield to that pressure.
I think that it is a bad idea to change the Scheme language when using an
alternate reader or syntax system which gives standard Scheme is a
fairly easy thing to do. I see no restriction in experimentation.
The *problem* I see with making #\: reserved is in portability of the above
systems. I may not have access to the implementation of Scheme which I am
using. If I want to experiment with random-module-package and the
implementation of Scheme I am using treats #\: as a comment character, I
have to bash or rewrite the reader just to get the sources I want to try out
to lex properly. If I can read symbols containing #\:, then I can
post-process the list structure which I can read using a standard reader.
I am in a much better position for experimentation if I can portably share
experiments without having to bash the implementation. Making #\: reserved
works against this.
-Ken kend@mrloog.AL.TEK.COM
(mod1:foo 3 x mod2:bar) --> ((*value mod1 'foo) 3 x (*value mod2 bar))
∂29-Jun-89 2112 @mc.lcs.mit.edu,@mojave.stanford.edu:shap@sid.stanford.edu A month of mail...
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 29 Jun 89 21:11:51 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26611;
29 Jun 89 23:57 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 23:35:04 EDT
Received: from Mojave.Stanford.EDU by mintaka.lcs.mit.edu id aa26242;
29 Jun 89 23:34 EDT
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
id AA08964; Thu, 29 Jun 89 20:31:01 PDT
Message-Id: <8906300331.AA08964@mojave.Stanford.EDU>
Received: by sid; Thu, 29 Jun 89 20:33:39 pdt
Date: Thu, 29 Jun 89 20:33:39 pdt
From: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
To: kend@bloom.la.tek.com
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: A month of mail...
Date: Thu, 29 Jun 89 09:35:58 PDT
From: kend@bloom.la.tek.com
> Ken's comment sort of blew past a point I think is interesting. We
> might be able to satisfy both desires - mutability and immutability -
> by reserving some suitably small part of the namespace for system
> primitives, e.g. identifiers with names whose leading substring is
> "%primitive-"
>
> Jon
Sorry to belabor the point, but...
If you use a *different* namespace for the implementation environment than
for the user environment, you do *not* have to make immutable any names in
the user environment. If a user has a function to allow him access to the
implementation environment, he can be sure he is getting at a particular
primitive [barring syntactic transformations--see discussion in the
Syntactic Closures paper in the last L&FP Conf.]. By giving out an access
function without giving a mutation function, the implementation environment
is immutable *from the user's viewpoint* without doing anything special
[although you may want to do so for other reasons].
...All this without reserving any part of the user visable namespace.
-Ken kend@mrloog.LA.TEK.COM
This is all very true, unfortunately, my original message had a
thinko. What I think would be useful is to have a set of standard
function names that are reserved and not mutable by the user.
Continuing the thinko, I should have said "%standard-" instead of
"%primitive-".
Why do I like this?
It is possible in the current scheme semantics to permanently lose all
of the user-visible bindings to a standard function. While this is
from the perspective of non-fascism desirable, it also means that
low-level "system"-type code basically can't trust anything at all.
There are two reasons why we might want to think about introducing
immutable things like
%standard-car
%standard-cdr
...
1. To be able to recover bindings to the standard functions
2. To be able to write low-level code that really does know what it is getting.
I observe as a side note that introducing environments would solve the
problem, but that idea seems to cause a lot of pain in these parts.
In the absence of such a mechanism, I am putting this forth as an
alternative to think about.
The fact that there is no way that my code can feel safe about its
standard environment is a serious weakness in scheme from the
standpoint of implementation. I wouldn't want to give up the
mutability, but it would be awfully nice to be able to know what world
my code is living in.
As to mutability, you missed the issue of optimization, which is a
significant one in my view.
Ciao.
Jon
∂29-Jun-89 2129 @mc.lcs.mit.edu,@relay.cs.net,@mojave.stanford.edu:shap@sid.stanford.edu A month of mail...
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 29 Jun 89 21:29:49 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26830;
30 Jun 89 0:05 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 23:40:16 EDT
Received: from RELAY.CS.NET by mintaka.lcs.mit.edu id aa26257;
29 Jun 89 23:37 EDT
Received: from mojave.stanford.edu by RELAY.CS.NET id aa10029;
29 Jun 89 23:36 EDT
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
id AA08968; Thu, 29 Jun 89 20:32:48 PDT
Message-Id: <8906300332.AA08968@mojave.Stanford.EDU>
Received: by sid; Thu, 29 Jun 89 20:35:27 pdt
Date: Thu, 29 Jun 89 20:35:27 pdt
From: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
To: kend%bloom.la.tek.com@relay.cs.net
Cc: rrrs-authors%mc.lcs.mit.edu@relay.cs.net
In-Reply-To: kend%bloom.la.tek.com@relay.cs.net's message of Thu, 29 Jun 89 09:35:58 PDT <8906291636.AA12503@bloom.LA.TEK.COM>
Subject: A month of mail...
HOLD THE FIRE!
I just reread Ken's note. Yes, we need environments.
Jon
∂30-Jun-89 1052 @mc.lcs.mit.edu:chaynes@iuvax.cs.indiana.edu Draft agenda for 3rd IEEE Scheme standard meeting
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 30 Jun 89 10:52:46 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04440;
30 Jun 89 13:47 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Jun 89 13:44:31 EDT
Received: from IUVAX.CS.INDIANA.EDU by mintaka.lcs.mit.edu id aa04385;
30 Jun 89 13:43 EDT
Received: by iuvax.cs.indiana.edu
Date: Fri, 30 Jun 89 12:43:32 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Draft agenda for 3rd IEEE Scheme standard meeting
Message-ID: <8906301343.aa04385@mintaka.lcs.mit.edu>
A draft agenda follows for third meeting of the Scheme Working Group,
July 7th, 9:30am-5pm, Cambridge, MIT (room to be announced soon).
Suggestions for other agenda items are welcome.
1. Approve agenda.
2. Elect secretary.
3. Approve minutes of second meeting.
4. Discuss the numbers section of the standard draft.
5. Discuss proposals for differences between R4RS and the standard.
6. Discuss liaison with ISO WG-16. The question is whether we want to
formally submit a draft of our standard to the International
Standards Organization Lisp Working Group so that they may consider
the possibility of adopting our standard as an ISO standard. If we
decide to to submit, we must also draft an accompanying statement.
7. Establish time and place of next meeting.
∂30-Jun-89 1229 @mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu Location for 3rd IEEE Scheme standard meeting
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 30 Jun 89 12:28:55 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05495;
30 Jun 89 15:12 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Jun 89 15:06:43 EDT
Received: from [18.43.0.171] by mintaka.lcs.mit.edu id aa05271;
30 Jun 89 15:01 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Fri, 30 Jun 89 14:58:26 edt
Date: Fri, 30 Jun 89 14:58:26 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8906301858.AA19407@ZURICH.AI.MIT.EDU>
To: scheme-standard@ZURICH.ai.mit.edu
Cc: rrrs-authors@ZURICH.ai.mit.edu
Subject: Location for 3rd IEEE Scheme standard meeting
The room for the meeting on July 7th will be MIT room 37-252.
This room is called the Marlar Lounge, but few people know this, so
you should ask for 37-252 if lost.
Building 37's street address is
70 Vassar st. in Cambridge.
∂30-Jun-89 1535 @mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@tekchips.labs.tek.com R↑3.95RS: open-input-file open-output-file
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 30 Jun 89 15:35:30 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07943;
30 Jun 89 18:25 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Jun 89 18:22:10 EDT
Received: from RELAY.CS.NET by mintaka.lcs.mit.edu id aa07857;
30 Jun 89 18:18 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa11414; 30 Jun 89 18:18 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA17223; Fri, 30 Jun 89 15:19:54 PDT
Received: by tekirl.LABS.TEK.COM (5.51/7.0)
id AA11465; Fri, 30 Jun 89 15:16:30 PDT
Received: by tekchips.LABS.TEK.COM (5.51/6.24)
id AA05379; Fri, 30 Jun 89 15:19:14 PDT
Message-Id: <8906302219.AA05379@tekchips.LABS.TEK.COM>
To: rrrs-authors@mc.lcs.mit.edu
Cc: kend@mrloog.la.tek.com
Subject: R↑3.95RS: open-input-file open-output-file
Date: 30 Jun 89 15:19:12 PDT (Fri)
From: kend@tekchips.labs.tek.com
Both OPEN-INPUT-FILE and OPEN-OUTPUT-FILE are specified to `signal an
error' on failure. I would either like these to return #f on failure
or have 2 similar functions with such a behavior. The reason is for
programattic error recovery. As we do not yet have a standard error
system, I don't have a portable way within a (non-interactive) program
to recover from failure to open a file. On the other hand, it is
fairly easy for me to adapt to various error systems to signal an
error.
(define (OPEN-INPUT-FILE <filename>)
(let ( (port (%primitive-open-input-file <filename>)) )
(if port ; #f on failure
port
(system-specific-error "Can't open file \"~A\" for input"
<filename>)
) ) )
I can see the argument that returning #f or some such can be
interpreted as signalling an error, but I would prefer something I can
reliably use in a conditional and a behavior which is guarenteed not
terminate my [batch, system, etc] program. Even "(not (input-port?
port))" is something I can test [although I would prefer #f].
Does anyone remember the rationale for this?
-Ken kend@mrloog.LA.TEK.COM
∂30-Jun-89 2123 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #149
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 30 Jun 89 21:23:39 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00507;
1 Jul 89 0:18 EDT
Date: 1 JUL 89 00:08:33 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #149
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907010018.aa00507@mintaka.lcs.mit.edu>
Scheme Digest #149 1 JUL 89 00:08:33 EDT
Today's Topics:
PC-Scheme
Draft agenda for 3rd IEEE Scheme standard meeting
Learning Scheme as a first language
----------------------------------------------------------------------
Date: Friday, 30 June 1989 08:55:44 TUR
From: Oguz ALGAN <ETIFIZ02%TREARN.BITNET@mitvma.mit.edu>
Subject: PC-Scheme
Message-ID: <8906300940.aa01822@mintaka.lcs.mit.edu>
Hello,
I want to learn the current version of the Texas Instrument's PC-Scheme Lisp.
And Do you know how can obtain the PC-Scheme's REFERANCE MANUAL or a book
that tells me about PC-SCHEME's language features.
Thanks in advance.
Oguz ALGAN,
ETIFIZ02@TREARN
------------------------------
Date: Fri, 30 Jun 89 12:35:31 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
Subject: Draft agenda for 3rd IEEE Scheme standard meeting
Message-ID: <8906301335.aa04323@mintaka.lcs.mit.edu>
A draft agenda follows for third meeting of the Scheme Working Group,
July 7th, 9:30am-5pm, Cambridge, MIT (room to be announced soon).
Suggestions for other agenda items are welcome.
1. Approve agenda.
2. Elect secretary.
3. Approve minutes of second meeting.
4. Discuss the numbers section of the standard draft.
5. Discuss proposals for differences between R4RS and the standard.
6. Discuss liaison with ISO WG-16. The question is whether we want to
formally submit a draft of our standard to the International
Standards Organization Lisp Working Group so that they may consider
the possibility of adopting our standard as an ISO standard. If we
decide to to submit, we must also draft an accompanying statement.
7. Establish time and place of next meeting.
------------------------------
Date: 28 Jun 89 17:10:22 GMT
From: Dave McKellar <jarvis.csri.toronto.edu!utgpu!utzoo!yunexus!intacc!mckellar@rutgers.edu>
Subject: Learning Scheme as a first language
Message-Id: <1989Jun28.131023.1031@intacc.uucp>
Does anyone know of an easy-reading book about scheme.
If there is one I hope to use it as a text for a course
teaching scheme as a first computer language.
Please e-mail any reply to me as I dont read the news
regularly. I will post a summary if there is any
response. Thanks alot.
--
----------
{uunet,watmath,utzoo}!mnetor!intacc!mckellar "Taste is a matter of taste."
----------
------------------------------
End of Scheme Digest
********************
∂01-Jul-89 0447 @mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu R↑3.95RS: open-input-file open-output-file
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 1 Jul 89 04:47:14 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04689;
1 Jul 89 7:41 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Jul 89 07:38:38 EDT
Received: from [18.43.0.171] by mintaka.lcs.mit.edu id aa04621;
1 Jul 89 7:34 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Sat, 1 Jul 89 07:31:50 edt
Date: Sat, 1 Jul 89 07:31:50 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8907011131.AA22190@ZURICH.AI.MIT.EDU>
To: kend@tekchips.labs.tek.com
Cc: rrrs-authors@mc.lcs.mit.edu, kend@mrloog.la.tek.com
In-Reply-To: kend@tekchips.labs.tek.com's message of 30 Jun 89 15:19:12 PDT (Fri) <8906302219.AA05379@tekchips.LABS.TEK.COM>
Subject: R↑3.95RS: open-input-file open-output-file
Date: 30 Jun 89 15:19:12 PDT (Fri)
From: kend@tekchips.labs.tek.com
Both OPEN-INPUT-FILE and OPEN-OUTPUT-FILE are specified to `signal an
error' on failure. I would either like these to return #f on failure
or have 2 similar functions with such a behavior. The reason is for
programattic error recovery. As we do not yet have a standard error
system, I don't have a portable way within a (non-interactive) program
to recover from failure to open a file. On the other hand, it is
fairly easy for me to adapt to various error systems to signal an
error.
(define (OPEN-INPUT-FILE <filename>)
(let ( (port (%primitive-open-input-file <filename>)) )
(if port ; #f on failure
port
(system-specific-error "Can't open file \"~A\" for input"
<filename>)
) ) )
I can see the argument that returning #f or some such can be
interpreted as signalling an error, but I would prefer something I can
reliably use in a conditional and a behavior which is guarenteed not
terminate my [batch, system, etc] program. Even "(not (input-port?
port))" is something I can test [although I would prefer #f].
Does anyone remember the rationale for this?
-Ken kend@mrloog.LA.TEK.COM
I'd rather see new procedures which probe read/write accesibility of
files. One of the things I detest about the C culture is the
convention that procedures return 0 (or -1 sometimes) when things
fail, and never generate errors. Although a conscientious programmer
will write reasonable code given this convention, I think that it
strongly encouages carelessness and poor coding (errors propagate and
are not "detected" until much later, when the program "core dumps").
I would therefore oppose changing these procedures, or even
introducing virtually identical ones that return #f.
∂01-Jul-89 2126 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #150
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 1 Jul 89 21:26:46 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11262;
2 Jul 89 0:17 EDT
Date: 2 JUL 89 00:08:30 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #150
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907020017.aa11262@mintaka.lcs.mit.edu>
Scheme Digest #150 2 JUL 89 00:08:30 EDT
Today's Topics:
Location for 3rd IEEE Scheme standard meeting
----------------------------------------------------------------------
Date: Sat, 1 Jul 89 07:32:26 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8907011132.AA22198@ZURICH.AI.MIT.EDU>
Subject: Location for 3rd IEEE Scheme standard meeting
The room for the meeting on July 7th will be MIT room 37-252.
This room is called the Marlar Lounge, but few people know this, so
you should ask for 37-252 if lost.
Building 37's street address is
70 Vassar st. in Cambridge.
------------------------------
End of Scheme Digest
********************
∂02-Jul-89 1434 @mc.lcs.mit.edu,@mojave.stanford.edu:shap@sid.stanford.edu R↑3.95RS: open-input-file open-output-file
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 2 Jul 89 14:33:57 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18131;
2 Jul 89 17:26 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 2 Jul 89 17:23:57 EDT
Received: from Mojave.Stanford.EDU by mintaka.lcs.mit.edu id aa18104;
2 Jul 89 17:22 EDT
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
id AA12753; Sun, 2 Jul 89 14:19:54 PDT
Message-Id: <8907022119.AA12753@mojave.Stanford.EDU>
Received: by sid; Sun, 2 Jul 89 14:22:27 pdt
Date: Sun, 2 Jul 89 14:22:27 pdt
From: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
To: jinx@ZURICH.ai.mit.edu
Cc: kend@tekchips.labs.tek.com, rrrs-authors@mc.lcs.mit.edu,
kend@mrloog.la.tek.com
In-Reply-To: "Guillermo J. Rozas"'s message of Sat, 1 Jul 89 07:31:50 edt <8907011131.AA22190@ZURICH.AI.MIT.EDU>
Subject: R↑3.95RS: open-input-file open-output-file
I agree with jinx. Having procedures return out-of-bound return
values to signal an error encourages all sorts of bad programming
habits, and has the further unfortunate property that it forces the
error detection/recovery code to be propagated to all of the calls if
I want to be well behaved.
In the absence of an error mechanism, though, it would be useful to
have an interim solution for people who need to write programs.
Writing a probing function doesn't get the job done - there is a race
condition between the time the file is probed and the time the open
happens. Ultimately, what is needed is the ability to pass a recovery
continuation to the open procedure so that one has a chance to come
back on failure.
Unfortunately this opens several cans of worms:
1. What should the error mechanism be [I like passing an error
continuation, but you may not.]
2. How can we standardize the set of possible errors so that
the error continuation can do something useful?
3. How do we decide which errors are recoverable.
I think that each of these issues takes considerable thought to get
right.
I would be interested to learn what mechanisms people have
experimented with and how well they work.
Jon
∂02-Jul-89 2200 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #151
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 2 Jul 89 22:00:35 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21144;
3 Jul 89 0:46 EDT
Date: 3 JUL 89 00:09:16 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #151
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907030046.aa21144@mintaka.lcs.mit.edu>
Scheme Digest #151 3 JUL 89 00:09:16 EDT
Today's Topics:
OOP in Scheme
----------------------------------------------------------------------
Date: 2 Jul 89 07:31:07 GMT
From: Brian of ASTD-CP <brian@jade.berkeley.edu>
Subject: OOP in Scheme
Message-Id: <1404@jato.Jpl.Nasa.Gov>
; methods2.scm
;
; ===============================================================
; Brian Beckman | brian@topaz.jpl.nasa.gov
; Mail Stop 510-202 | (818) 397-9207
; Jet Propulsion Laboratory |
; Pasadena, CA 91109 | 30 June 1989
; ===============================================================
; INTRODUCTION
;
; This is a tiny object-oriented programming system with multiple
; inheritance and error handling. It is modeled after the message
; passing modules in Chapter 3 of Abelson & Sussman. It is
; implemented in ``pure'' Scheme, without macros or syntax
; extensions.
;
; This programming system is implemented as a technique, or
; programming convention, with some helper routines. The programming
; convention is not enforced, as we choose to avoid syntax-extensions
; for portability's sake. The technique is illustrated in this file
; with a few examples. In example one, a parent class, named
; ``parent,'' passes its attributes to a child named ``child.'' In
; example two, two parents, ``mother'' ``fater'', pass their attributes
; to a child class, ``daughter.'' The reader will perceive the technique
; by generalization from these examples and will be able to apply it
; to his or her own problems.
;
; Every class is represented by its constructor procedure. This
; procedure returns a message dispatching procedure. The message
; dispatching procedure should be named ``self'' so that an object can
; conveniently send messages to itself. However, ``self'' is an
; internal name not known outside the constructor.
;
; In summary, classes are represented by constructor procedures, and
; objects, or instances of classes, are represented by message
; dispatching procedures. The present version of ``methods'' does not
; support code sharing, so every instance of a class has its own
; private copies of the method code. We expect to implement code
; sharing in a later version of ``methods''.
;
; The message dispatching procedure walks the multiple inheritance
; hierarchy upwards until it finds an object that can understand a
; message, starting with itself. If no object that can understand the
; message is found, a global error procedure is called.
;
; IMPLEMENTATION
;
; Error processing is challenging. We should like to have two modes.
; In ``normal mode'', an error is reported only by the first receiver
; of a message. In ``debug mode'', an inheritance traceback should be
; given whereby every object in an inheritance hierarchy will report
; when it fails to recognize a given message. The following variable
; represents that mode. (For simplicity, this object is hidden only
; by its name, which is unusual enough that it is unlikely to be
; trammeled by an application. This is not the recommended technique
; for data hiding. Data hiding ought to be implemented through the
; techniques shown in this file! However, since this error handling
; part of the methods package is considered system programming,
; certain liberties in style are justifiable. There are in fact, good
; technical reasons for the error handling code to be implemented with
; global variables, which the perceptive reader will be able to
; deduce.)
(define **method-mode** 'normal-method-mode)
; The user can set these modes as follows.
(define (set-debug-method-mode)
(set! **method-mode** 'debug-method-mode))
(define (set-normal-method-mode)
(set! **method-mode** 'normal-method-mode))
(define (reset-debug-method-mode) ;;; synonym
(set! **method-mode** 'normal-method-mode))
; and test them with the following routine:
(define (test-debug-method-mode)
(eq? **method-mode** 'debug-method-mode))
; Before presenting the examples of classes and objects, some helper
; routines are needed.
;
; When an object cannot recognize a message, and none of its ancestor
; objects can recognize it, the object creates an error procedure and
; returns it as the result of the message dispatcher.
(define **method-error-class-name** "No class name.")
(define **method-error-message** 'no-message)
(define (error-method . junk-args)
(display **method-error-class-name**)
(display ": uknown message: '")
(display **method-error-message**)
(newline)
())
(define (make-error-method class-name msg)
(set! **method-error-class-name** class-name)
(set! **method-error-message** msg)
error-method)
; The procedure that walks the inheritance hierarchy must cooperate
; in the error handling.
(define (search-supertypes supers msg)
(define method ())
(if (test-debug-method-mode)
(begin
(display "Searching...")
(newline)))
(cond
( (null? supers) () )
( (begin
(set! method ((car supers) msg))
(eq? method error-method))
(if (test-debug-method-mode)
(error-method))
(search-supertypes (cdr supers) msg) )
( else method )))
; This procedure implements the inheritance of methods. It is greatly
; complicated by proper error handling. Without error handling, the
; routine would resemble the following, which is much easier to
; understand (without error handling, the programming convention is
; that an object that does not understand a message returns the
; unexecutable method ``()'').
;
; (define (search-supertypes supers msg)
; (cond
; ( (null? supers) () )
; ( ((car supers) msg) )
; ( else (search-supertypes (cdr supers) msg) )))
;
; The actual routine, with proper error handling, works as follows. A
; local variable, ``method'', is defined. Its value is not important
; to begin with. If debugging is on, we print a message telling the
; user that the inheritance hierarchy is being searched. Then, the
; list of supertypes is investigated. If the list is empty, we return
; nil, which signals the caller to create and return the error-method,
; as we shall see in the examples later. If the list is not empty, we
; pass the message to the first supertype in the list. The return
; value is assigned to the local variable ``method''. If the returned
; method is the one and only global error-method, then the supertype,
; and, recursively, all its supertypes, did not know the message.
; If debugging is on, we execute the returned error-method, contributing
; to the aforementioned inheritance traceback. Finally, we return
; the value of a recursive call of search-supertypes on the remainder
; of the list of supertypes. If the returned method is not the
; error-method, then the supertype did understand the message after
; all somewhere in the hierarchy, and the returned method is the
; return value of this procedure.
;
; Note that the list of supertypes is searched in order from front
; to back. The first match of a message results in the successful
; finding of a method. The order of supertypes in the list is
; significant only when more than one supertype can understand
; a given message. The earlier members of the list will shadow
; the later ones. In some object-oriented programming systems, one
; refers to the ``overriding'' of methods. The shadowing in
; ``methods'' is our form of method overriding, and it is under
; explicit control of the programmer who sets the order of supertypes
; in the list of supertypes.
;
; In summary, search-supertypes passes the message to the ancestors,
; in pre-order, returning the first method found.
;
; The next helper routine passes a message, and a variable number of
; arguments, to all the parents of an object. For side effects, it
; executes any methods found. Parents are defined as
; first level ancestors.
(define (for-all-parents supers msg . args)
(let ( (method-list
(map (lambda (supertype) (supertype msg)) supers))
(for-proc
(lambda (method) (apply method args))) )
(for-each for-proc method-list)))
; With the current programming convention, it is not possible to pass
; a message to all ancestors and execute the methods for side-effect
; without explicit cooperation on the part of the objects involved. In
; other words, the procedure ``for-all-ancestors'', analogous to
; ``for-all-parents'', cannot be implemented in the current version of
; the methods package. The reason is that the convention calls for
; every class to call ``search-supertypes'', which stops when it finds
; a method. The convention would have to be augmented so that objects
; would call ``find-all-methods'' (defined below) on an appropriate
; message. Since we expect the need for ``for-all-ancestors'' to be
; fairly rare, the necessary changes to the methods package will be
; reserved for a future version.
(define (find-all-methods supers msg)
(cond
( (null? supers) () )
( else (cons ((car supers) msg)
(find-all-methods (cdr supers) msg)) )))
; EXAMPLES (cut here to end of file to throw examples away)
;
; Our first example class, or object type, is ``parent'', represented
; by the following constructor procedure.
(define (new-parent arg)
(let ((state-var (* arg arg))
(supers ()))
(define (report-state-var)
(display state-var)
(newline)
state-var)
(define (update-state-var arg)
(set! state-var (* arg arg)))
(define (echo arg)
(display arg) (newline))
(define (self msg)
(cond
( (eq? msg 'report) report-state-var )
( (eq? msg 'update) update-state-var )
( (eq? msg 'echo) echo )
( (search-supertypes supers msg) )
( else (make-error-method "Parent" msg) )))
self))
; This class, or constructor procedure, completely illustrates, by
; example, the programming convention of the ``methods'' technique.
; The constructor takes a single argument, whose square it stores in a
; local state variable. Another state variable, the list of
; supertypes, is set to nil, since this class is at the root of an
; inheritance hierarchy. Three methods are defined, one that reports
; and returns the current value of the state variable, one that sets
; the state variable equal to a new square, and one that merely echoes
; its argument. A method dispatching procedure, conventionally named
; ``self'', tests a given message against three symbols and returns
; the corresponding method if a match is found. If no match is found,
; the list of supertypes is searched for a match. In the case of this
; class, ``parent'', the search is purely formal, to illustrate how it
; should be done, since ``parent'' has no ancestors. However, if a
; match were found among the list of supertypes, the method would be
; returned. Note how the search relys on the fact that any non-nil
; result is treated as a successful ``cond'' clause, terminating the
; ``cond'' statement. Search-supertypes returns nil only when a match
; is not found. Finally, if no match is found locally or among the
; supertypes, an appropriate error-method is pseudo-created and
; returned.
;
; We now test this class by making an instance and passing it
; messages.
(define p (new-parent 42))
((p 'report))
((p 'update) 69)
((p 'report))
((p 'echo) (list 1 2 3))
; We test error handling:
((p 'bogus))
(set-debug-method-mode)
((p 'bogus))
(reset-debug-method-mode)
((p 'bogus) 'here 'are 'some 'junk 'arguments)
; Continuing this example, let us define a child class inheriting
; all attributes and methods of the parent. Note the attributes of
; the parent are only accessible through the parent's method
; discipline. This is a strict form of inheritance, and the default
; in C++, for example. (C++ allows the programmer to override
; ancestors' access discipline, at his own peril.)
(define (new-child arg1 arg2)
(let* ( (leg1 (* arg1 arg1))
(leg2 (* arg2 arg2))
(hypotenuse (+ leg1 leg2))
(supers (list
(new-parent hypotenuse))) )
(define (report)
(for-all-parents supers 'report)
(display "Leg1 = ") (display (sqrt leg1)) (newline)
(display "Leg2 = ") (display (sqrt leg2)) (newline)
(display "Hypo = ") (display (sqrt hypotenuse)) (newline))
(define (update-leg1 val)
(set! leg1 (* val val))
(set! hypotenuse (+ leg1 leg2)))
(define (update-leg2 val)
(set! leg2 (* val val))
(set! hypotenuse (+ leg1 leg2)))
(define (self msg)
(cond
( (eq? msg 'report) report )
( (eq? msg 'update-leg1) update-leg1 )
( (eq? msg 'update-leg2) update-leg2 )
( (search-supertypes supers msg) )
( else (make-error-method "Child" msg) )))
self))
; We now test the child type.
(define c (new-child 3 4))
((c 'report)) ;;; passes message to all parents
((c 'update-leg1) 5)
((c 'update-leg2) 12)
((c 'report))
((c 'echo) '(foo bar)) ;;; msg known only in the parent
((c 'bogus) 'baz 'rat)
(set-debug-method-mode)
((c 'bogus) 'baz 'rat)
(reset-debug-method-mode)
((c 'bogus) 'baz 'rat)
; The last example, presented without detailed narrative, shows a
; slightly deeper inheritance hierarchy. The leaf is a type named
; ``daughter''. Its two parent classes are ``mother'' and ``father''.
; In turn, every mother has an ``estate'' and a ``religion'' (please
; excuse the somewhat strained metaphor of inheritance; this is just
; a little example).
(define (new-estate value)
(let ((value value)
(supers ()))
(define (report)
(display "Estate = $") (display value) (newline))
(define (what-value) value)
(define (increase amount) (set! value (+ value amount)))
(define (decrease amount) (set! value (- value amount)))
(define (self msg)
(cond
( (eq? msg 'report) report )
( (eq? msg 'what-estate) what-value )
( (eq? msg 'increase) increase )
( (eq? msg 'decrease) decrease )
( (search-supertypes supers msg) )
( else (make-error-method "Estate" msg) )))
self))
(define (new-religion theReligion)
(let ((religion theReligion)
(supers ()))
(define (report) (display "Religion = ") (display religion) (newline))
(define (what-religion) religion)
(define (convert theNewReligion) (set! religion theNewReligion))
(define (self msg)
(cond
( (eq? msg 'report) report )
( (eq? msg 'convert) convert )
( (eq? msg 'what-religion) what-religion )
( (search-supertypes supers msg) )
( else (make-error-method "Religion" msg) )))
self))
(define (new-father eye-color)
(let ((eye-color eye-color)
(supers ()))
(define (report) (display "Father's eye color = ")
(display eye-color) (newline))
(define (what-eye-color) eye-color)
(define (self msg)
(cond
( (eq? msg 'report) report )
( (eq? msg 'what-eye-color) what-eye-color )
( (search-supertypes supers msg) )
( else (make-error-method "Father" msg) )))
self))
(define (new-mother eye-color estate religion)
(let ((eye-color eye-color)
(supers (list
(new-estate estate)
(new-religion religion))))
(define (report)
(for-all-parents supers 'report)
(display "Mother's eye color = ")
(display eye-color) (newline))
(define (what-eye-color) eye-color)
(define (self msg)
(cond
( (eq? msg 'report) report )
( (eq? msg 'what-eye-color) what-eye-color )
( (search-supertypes supers msg) )
( else (make-error-method "Mother" msg) )))
self))
(define (new-daughter eye-color)
(let* ((eye-color eye-color)
(parents-eye-color
(if (eq? eye-color 'blue) 'blue 'brown))
(supers (list
(new-father parents-eye-color)
(new-mother parents-eye-color 500000 'Jewish))))
(define (report)
(for-all-parents supers 'report)
(display "Daughter's eye color = ")
(display eye-color)
(newline))
(define (what-eye-color) eye-color)
(define (self msg)
(cond
( (eq? msg 'report) report )
( (eq? msg 'what-eye-color) what-eye-color )
( (search-supertypes supers msg) )
( else (make-error-method "Daughter" msg) )))
self))
(define dbl (new-daughter 'blue))
((dbl 'report))
((dbl 'convert) 'muslim)
((dbl 'report))
((dbl 'increase) 50000)
((dbl 'report))
(define dbr (new-daughter 'brown))
((dbr 'report))
((dbr 'decrease) 250000)
((dbr 'report))
((dbr 'bogus))
(set-debug-method-mode)
((dbr 'bogus))
(reset-debug-method-mode)
------------------------------
End of Scheme Digest
********************
∂03-Jul-89 2219 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #152
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 3 Jul 89 22:19:37 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03991;
4 Jul 89 1:09 EDT
Date: 4 JUL 89 00:09:20 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #152
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907040109.aa03991@mintaka.lcs.mit.edu>
Scheme Digest #152 4 JUL 89 00:09:20 EDT
Today's Topics:
OOP in Scheme (addendum)
AI NEWS FROM IEEE COMPUTER SOCIETY
Calculuses (sp?) for Scheme, and R*RS (again)
----------------------------------------------------------------------
Date: 3 Jul 89 08:16:05 GMT
From: Brian of ASTD-CP <brian@jade.berkeley.edu>
Subject: OOP in Scheme (addendum)
Message-Id: <1406@jato.Jpl.Nasa.Gov>
; methods.scm (ADDENDUM)
;
; ===============================================================
; Brian Beckman | brian@topaz.jpl.nasa.gov
; Mail Stop 510-202 | (818) 397-9207
; Jet Propulsion Laboratory |
; Pasadena, CA 91109 | 30 June 1989
; ===============================================================
; There are two ways to invoke a method in an object. The
; first is to send the object a message, getting back a procedure.
; This procedure can then be invoked at will on an appropriate
; set of arguments. Such an idiom usually results in expressions
; like the following:
;
; ((foo 'do-it) arg1 arg2)
;
; This is fairly readable and a fine idiom, but it has its
; limitations. Suppose that this expression were to result in
; another object, to which we should like to send the message
; 'baz with the arguments 'rat and 'ter. Then we should write
; the following:
;
; ((((foo 'do-it) arg1 arg2) 'baz) 'rat 'ter)
;
; The number of leading parentheses is a problem. It is easy
; to devise nested message passing expressions that are
; much more difficult to write than to devise, merely because of
; the number of leading parentheses that must be presaged. Lisp
; already has a problem with closing parentheses; we don't want
; to compound the felony in this package by introducing a
; corresponding problem with opening parentheses.
;
; We need a ``send'' routine that does little more than reduce
; the need for leading parenthese. This is, admittedly, merely
; a syntactic issue. Consider the following, which is the second
; way to send a message to an object:
(define (send object msg . args)
(apply (object msg) args))
; The earlier example message passing expressions can now be
; much more easly written much more nicely, as follows:
;
; (send object 'msg arg1 arg2)
;
; and
;
; (send (send object 'msg arg1 arg2) 'baz 'rat 'ter)
------------------------------
Date: Mon, 03 Jul 89 07:49 EDT
From: DYU%NCCIBM1.BITNET@mitvma.mit.edu
Subject: AI NEWS FROM IEEE COMPUTER SOCIETY
Message-ID: <8907030752.aa24699@mintaka.lcs.mit.edu>
WHAT IS THE TASK FORCE ON EXPERT SYSTEMS?
The IEEE Computer Society announces the formation of a
Task Force on Expert Systems Applications. The purpose of the
Task Force is to support interest in the development and use of
expert systems applications. The IEEE Computer Society, which
has over 100,000 members worldwide, authorized the creation of
the Task Force at a meeting of its Technical Activities Board
(TAB) held March 2nd in San Francisco, CA.
The objectives of the Task Force are to improve the
abilities of organizations and individuals to work with expert
systems technologies. The Task Force will sponsor activities at
the national and international levels, but also support local
events. The Task Force will publish a newsletter, exchange
electronic mail, provide speakers for conferences, organize
tutorials, symposiums, and convene meetings on standards either
on its own initiative or jointly with other IEEE Computer Society
functions.
The Importance of Expert Systems
MIS and end users are experiencing an explosion of
interest and activity in expert systems applications in almost
all sectors of business, government, and education. This is
taking place due to the wide distribution of expert system shells
on personal computers and workstations. It is a remarkable
change in the field of artificial intelligence in which
developers usually rely on specialized computer platforms and
programming languages.
Expert systems are the most mature and resilient products
to emerge from the AI community, and they are being adopted by
corporations and government departments to improve productivity.
They are doing this because the applications of expert systems to
specific knowledge intensive systems return high yields. Success
stories for expert systems are more common now than two years
ago. A current estimate is there are 2,000 operational expert
systems and 80% of them on running on personal computers.
The Value of the Task Force
The greatest value which will be derived from
participating in the Task Force will come from regular
discussions among Task Force participants. In some ways, this
will resemble the informal interactions of a user group. In
other ways it will compliment many of the professional activities
of the IEEE Computer Society.
Within these broad themes, there are many diverse
interests, including business activities such as banking and
finance, manufacturing and service functions, medical practice,
government functions, including the military, and education.
These interests will be addressed through locally sponsored and
nationally significant activities including conferences,
workshops, lectures, a newsletter, and other appropriate
mechanisms.
Membership
All meetings of the Task Force are be open to the public
and will be announced ahead of time in the news media. Anyone
who has an interest in the objectives of the Task Force is
invited to attend its functions and participate in its
activities. Membership in the IEEE Computer Society is not
required to attend our meetings. Since the Task Force is
oriented toward development and use of expert systems
applications, we expect and encourage the interest of vendors of
computer hardware, software, and services. Future activities of
the Task Force will be developed consistent with the goals and
objectives of the IEEE Computer Society.
For additional information, call Dan Yurman, Chairman, at
202-475-6754 9-5 EST. MCI Mail: 364-1277
Mailing address:
-----------------------------
Task Force on Expert Systems
c/o TAB Coordinator
IEEE Computer Society
1730 Massachusetts Ave., NW
Washington, DC 20036.
IEEE Computer Society
Task Force on Expert Systems
Roles & Responsibilities
Chair: This role is responsible for leadership and
technical direction of the Task Force. The Chair maintains the
vitality of the group by coordinating activities such as
speakers, seminars, conferences, workshops, tutorials, workgroups
on standards, and communications with members including
newsletters and electronic mail. The Chair appoints the other
leadership figures of the Task Force.
Dan Yurman, Chairman
Information Management Staff
Office of Solid Waste & Emergency Response
U.S. Environmental Protection Agency
401 M St., SW; (OS-110)
Washington, DC 20460 202-475-6754
Vice-Chairs: The Chair appoints Vice-Chairs for the
purpose of carrying out functions of the Task Force. All Vice
Chairs receive logistical support from the IEEE Computer
Society's administration office which is located in Washington,
DC. Vice-Chairs are responsible for recruiting volunteers to
carry out their responsibilities. Vice-Chairs are delegated the
authority to appoint such committee chairs as may be needed, e.g.
newsletter editor, workshop convener, etc.
Communications: Responsible for all communications with
members, the public, and other professional societies. Develops
and publishes a newsletter, establishes electronic mail exchange,
and sustains publicity for Task Force Events. Keeps a record of
all meetings. Serves as a point of contact with IEEE Expert
magazine and IEEE Computer magazine.
Sandra Hoffman, Vice Chair for Communications
Systems Analyst
Congressional Budget Office
2nd & D, SW; Room 450
Washington, DC 20515 202-226-2886
Meetings: Responsible for developing a program of
meetings featuring speakers on topics of interest to the
membership. Works with other Vice- Chairs to handle local
arrangements. Establishes working groups for tutorials and
seminars on significant topics.
Randy Manner, Vice Chair for Meetings
Manager - Expert Systems Group
American Management Systems
1777 N. Kent St.
Arlington, VA 22209 703-841-6849
Conferences: This Vice-Chair has a liaison role for the
IEEE Computer Society "Expert Systems in Government" Conference,
and for other IEEE Computer Society conferences which emphasize
applications of artificial intelligence and expert systems.
Also, this Vice Chair is responsible for coordinating the working
relationship of the Task Force with conferences on expert systems
sponsored by other professional societies.
Jerry Feinstein, Vice Chair for Conferences
Vice President
Phase-Linear Systems/ICF
9300 Lee Highway
Fairfax, VA 22031 703-934-3280
Standards: Develops working groups composed of users,
industry, and academia to address issues related to hardware or
software standards for expert systems applications.
Captain Dave Howell, Vice Chair for Standards
Artificial Intelligence
Program Management Office
U.S. Air Force Logistics Command
HQ AFLC/MM-AI
Wright Patterson AFB,
Ohio 45433 513-257-2571
Industry Relations: Establishes and maintains
communications with hardware and software vendors, developers,
and other commercial as well as not-for-profit providers of
expert systems applications. Provides for demonstration or
poster sessions on the latest technological developments.
Joseph Schmuller, Vice Chair for Industry Relations
Senior Knowledge Engineer
CDM Federal Programs Corp.
13135 Lee Jackson Highway
Fairfax, VA 22033 703-968-0900
Treasurer: Responsible for keeping track of Task Force
finances, for fund raising including setting up a means to cover
costs, and solicitations of "in kind" contributions.
Vacant
Membership: Responsible for developing and implementing
a membership recruitment campaign for the Task Force working at
the national level. Works with other Vice-Chairs to carry out
these functions. Establishes and maintains liaison with IEEE
Computer Society Chapters and Area Activities Boards as well as
other Task Forces and Technical Committees.
Vacant
Task Force on Expert Systems
c/o TAB Coordinator
IEEE Computer Society
1730 Massachusetts Ave. NW
Washington, DC 20036
---------------------------
Membership Mailing List and Activity Preference
NOTE: If you can't wait for the mail,
call a Vice Chair and volunteer today!
Please complete this form and return it to:
Dan Yurman, Chair
Task Force on Expert Systems
c/o US EPA (OS-110)
401 M St., SW
Washington, DC 20460
Ph: 202-475-6754
Please provide any suggestions or comments in the margins of the
paper. Thank you.
Name:________________________________________________________
Title:_______________________________________________________
Organization:________________________________________________
Address:_____________________________________________________
_____________________________________________________________
City:________________________________________________________
State: ______ ZIP:__________
Daytime Phone: ______ ______ ____________
Electronic mail:_____________________________________________
Please indicate the activities you would like to
volunteer your time and talents. You will be contacted soon.
You do not have to be a member of the IEEE Computer Society to
participate in the activities of the Task Force on Expert
Systems. At this time there is no charge to be placed on our
mailing list. Within the next six months there may be a nominal
dues charge to continue to receive these materials.
------------------------------
Date: 3 Jul 89 17:21:18 GMT
From: John Lacey <lacey@tcgould.tn.cornell.edu>
Subject: Calculuses (sp?) for Scheme, and R*RS (again)
Message-Id: <8313@batcomputer.tn.cornell.edu>
Does anyone have references to calculus bases for Scheme (such as
the lambda calculus, and the one by Matthias Felleisen)? That is,
references that deal with these directly in terms of Scheme (of
course those for the latter will, as it was designed for Scheme).
Also, I am *still* looking for the text of the Revised * Report on
Scheme. Where can I find it? Is there an E-mailable copy someplace?
Sorry about posting these types of questions, but the libraries here
are staffed with completely inadequate electronic searching systems,
and summer help.
--
John Lacey | Internet: lacey@tcgould.tn.cornell.edu
running unattached | BITnet: lacey@crnlthry
| UUCP: cornell!batcomputer!lacey
"Whereof one cannot speak, thereof one must remain silent." ---Wittgenstein
------------------------------
End of Scheme Digest
********************
∂04-Jul-89 1707 @mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@bloom.la.tek.com R↑3.95RS: open-input-file open-output-file
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 4 Jul 89 17:07:37 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11960;
4 Jul 89 20:06 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 4 Jul 89 20:03:43 EDT
Received: from RELAY.CS.NET by mintaka.lcs.mit.edu id aa11937;
4 Jul 89 20:02 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa06940; 4 Jul 89 20:02 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA29240; Tue, 4 Jul 89 17:04:33 PDT
Received: by dadla.LA.TEK.COM (5.51/6.24)
id AA14612; Tue, 4 Jul 89 16:58:16 PDT
Received: from localhost.ARPA by bloom.LA.TEK.COM (1.2/6.24)
id AA16574; Tue, 4 Jul 89 17:03:03 pdt
Message-Id: <8907050003.AA16574@bloom.LA.TEK.COM>
To: jinx@ZURICH.ai.mit.edu, shap@sid.stanford.edu
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: R↑3.95RS: open-input-file open-output-file
Date: Tue, 04 Jul 89 17:02:59 PDT
From: kend@bloom.la.tek.com
>> from Ken Dickey
> Both OPEN-INPUT-FILE and OPEN-OUTPUT-FILE are specified to `signal an
> error' on failure. I would either like these to return #f on failure
> or...
>> from JINX
> I'd rather see new procedures which probe read/write accesibility of
> files. One of the things I detest about the C culture is the
> convention that procedures return 0 (or -1 sometimes) when things
> fail, and never generate errors. Although a conscientious programmer
> will write reasonable code given this convention, I think that it
> strongly encouages carelessness and poor coding (errors propagate and
> are not "detected" until much later, when the program "core dumps").
> I would therefore oppose changing these procedures, or even
> introducing virtually identical ones that return #f.
I would very much like to see an error handling mechanism specified in
R↑5RS. In the interrum, is the Scheme community going to have a standard in
which a non-interactive program dumps core because of a failed file open?
Although legal behavior, I find this most distressing.
-Ken kend@mrloog.LA.TEK.COM
∂05-Jul-89 1411 @mc.lcs.mit.edu,@decwrl.pa.dec.com:jmiller@crl.dec.com Responses to a month of mail
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89 14:11:29 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22410;
5 Jul 89 17:10 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 5 Jul 89 17:01:34 EDT
Received: from decwrl.pa.dec.com by mintaka.lcs.mit.edu id aa22221;
5 Jul 89 16:55 EDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
id AA03471; Wed, 5 Jul 89 13:55:01 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
for rrrs-authors@mc.lcs.mit.edu; id AA03471; Wed, 5 Jul 89 13:55:01 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
id AA05480; Wed, 5 Jul 89 16:56:21 EDT
Date: Wed, 5 Jul 89 16:53:13 EDT
From: jmiller@crl.dec.com
Message-Id: <8907052053.AA00249@peanut.DEC.COM>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden 29-Jun-89 1247 EDT's message of Thu, 29 Jun 89 12:59:40 EDT <8906291659.AA01277@crl.crl.dec.com>
Subject: Responses to a month of mail
Reply-To: JMiller%crl.dec@decwrl.pa.dec.com
I'd like to suggest that Pavel use "|" instead of ":" for his module
separator. It's currently illegal, and I believe that his argument
against its use (other dialects use it for an escape character) is
very weak. It also looks pretty good for just this purpose:
(module|submodule|procedure random-thing)
--Jim
∂05-Jul-89 1452 @mc.lcs.mit.edu,@decwrl.pa.dec.com:jmiller@crl.dec.com R↑3.95RS: open-input-file open-output-file
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89 14:52:43 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22838;
5 Jul 89 17:40 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 5 Jul 89 17:12:00 EDT
Received: from decwrl.pa.dec.com by mintaka.lcs.mit.edu id aa22391;
5 Jul 89 17:09 EDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
id AA05041; Wed, 5 Jul 89 14:08:52 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
for rrrs-authors@mc.lcs.mit.edu; id AA05041; Wed, 5 Jul 89 14:08:52 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
id AA05509; Wed, 5 Jul 89 17:10:29 EDT
Date: Wed, 5 Jul 89 17:07:22 EDT
From: jmiller@crl.dec.com
Message-Id: <8907052107.AA00259@peanut.DEC.COM>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Jonathan S. Shapiro 2-Jul-89 1422 PDT's message of Sun, 2 Jul 89 17:36:32 EDT <8907022136.AA03775@crl.crl.dec.com>
Subject: R↑3.95RS: open-input-file open-output-file
Reply-To: JMiller@crl.enet.dec.com
At the risk of opening an entire can of worms, what about passing an
optional flag in to OPEN-... specifying (if present and EQ? to #T)
that a return value of #F is valid. Thus "ordinary" programming would
omit the flag and generate errors; users like Ken (?) would have the
control they would like.
--Jim
∂05-Jul-89 1835 @mc.lcs.mit.edu:Pavel.pa@xerox.com Re: R↑3.95RS: open-input-file open-output-file
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89 18:35:52 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25164;
5 Jul 89 21:27 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 5 Jul 89 20:58:50 EDT
Received: from [13.0.12.232] by mintaka.lcs.mit.edu id aa24767;
5 Jul 89 20:54 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUL 89 17:53:42 PDT
Date: Wed, 05 Jul 89 17:53:24 PDT
From: Pavel.pa@xerox.com
Subject: Re: R↑3.95RS: open-input-file open-output-file
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890705-175342-7490@Xerox>
I share the distaste of some others for returning special values to signal
errors or other exceptional conditions. I would, also as others have
stated, prefer that we agree on enough of a condition facility that such
errors can be handled that way. I have designed (if that's the right word
for something so simple) a condition facility that I believe contains
little enough policy that we might all agree on it in time for R4RS.
Unsurprisingly, however, it depends upon the existence of a mechanism for
fluid binding, so I will hold off on proposing the condition facility until
after we agree on fluid binding. I think that we can probably come to an
easy agreement on that issue at this point, so I will send out a proposal
either today or tomorrow to get the ball rolling.
Pavel
∂05-Jul-89 1856 @mc.lcs.mit.edu:Pavel.pa@xerox.com Curried definition syntax
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89 18:56:37 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25478;
5 Jul 89 21:53 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 5 Jul 89 21:49:38 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa25369; 5 Jul 89 21:43 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUL 89 18:12:04 PDT
Date: Wed, 05 Jul 89 18:11:57 PDT
From: Pavel.pa@xerox.com
Subject: Curried definition syntax
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890705-181204-7527@Xerox>
I received only two responses to my proposal that we reinstate the
``curried'' syntax for definitions, dropped in the interval between RRRS
and R3RS. Both mentioned other possible extensions (type predicates on
arguments and variable-arity procedures) that might formally or
aesthetically clash with the additional syntax. Thus, at least until such
time as the fates of those possible extensions in the language are settled,
I'm willing to withdraw my proposal.
Pavel
∂05-Jul-89 1919 @mc.lcs.mit.edu:Pavel.pa@xerox.com Uniform definition semantics
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89 19:19:29 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25656;
5 Jul 89 22:06 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 5 Jul 89 21:49:47 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa25395; 5 Jul 89 21:46 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUL 89 18:44:39 PDT
Date: Wed, 05 Jul 89 18:44:30 PDT
From: Pavel.pa@xerox.com
Subject: Uniform definition semantics
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890705-184439-7576@Xerox>
I proposed that the syntax and semantics of programs and ``bodies'' be
identical, with the following syntax and the more-or-less obvious
semantics.
<program> ::= { <expression> | <definition> | (begin <program>) }*
John Ramsdell supported this proposal while holding out his own more
conservative one as a possible fallback position.
Jinx agreed that internal and external definitions should have the same
semantics, but would rather that we instead adopt the current LETREC-style
semantics of internal definitions. He points out that this is ``too
radical to be accepted by most people'' and prefers the status quo to my
proposal (and presumably to John's as well).
I don't know that it is the ``radical'' nature of Jinx's preference that
keeps me from supporting it. Rather, it is the combination of great
incompatibility (I would bet that the vast majority of non-trivial existing
Scheme programs would become illegal) and great inconvenience. For
example, I frequently define a set of procedures for manipulating values of
some type and then immediately define another variable, initializing it via
a call on one or more of those procedures. Under Jinx's semantics, that
code would cease to be correct and would have to be rewritten, first
defining the variable to have some nonsense value and then assigning the
proper value to it in a separate expression. This is obfuscatory and
useless.
As to the status quo, I cannot agree that two conflicting semantics are
better than a single compatible, useful, and intuitive one.
The only other response came from Ken Dickey (I think that's his last
name), who said the following:
I like the internal semantics and would like to change the name of the
special form used in interactive loops from "define" to something else
(e.g.
"defun"). The top-level-environment is an artifact of an interactive
system. We could make a naming distinction between uses/behaviors,
rather
than changing uses because of a name alias.
See above for my comments on the internal semantics.
I do not agree that the top-level environment has anything to do with the
interactive nature of some Scheme implementations. It has more to do with
a notion of a global namespace, shared among many distinct program
fragments (often stored in files). As such, definitions are simply
another, sometimes more convenient, syntax for the establishment of a
lexical contour, completely unrelated to interactivity. Thus, I see no
difference in the uses of internal and external definitions and therefore
wish they had the same behavior.
I am surprised that there have been no other comments; is one to assume
that the remainder of the list has no opinion on the subject?
Pavel
∂05-Jul-89 1941 @mc.lcs.mit.edu:Pavel.pa@xerox.com Reserving a character for experimentation
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89 19:41:43 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25830;
5 Jul 89 22:26 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 5 Jul 89 22:05:43 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa25624; 5 Jul 89 22:04 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUL 89 19:04:11 PDT
Date: Wed, 05 Jul 89 19:04:03 PDT
From: Pavel.pa@xerox.com
Subject: Reserving a character for experimentation
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890705-190411-7603@Xerox>
I think that Alan Bawden stated my position (and, in particular, my
reaction to some of the other comments on my proposal) quite completely and
adequately, so I'll answer only the comments since his note.
Ken Dickey (?) says:
The *problem* I see with making #\: reserved is in portability of the
above
systems. I may not have access to the implementation of Scheme which I
am
using. If I want to experiment with random-module-package and the
implementation of Scheme I am using treats #\: as a comment character, I
have to bash or rewrite the reader just to get the sources I want to try
out
to lex properly. If I can read symbols containing #\:, then I can
post-process the list structure which I can read using a standard
reader.
I am in a much better position for experimentation if I can portably
share
experiments without having to bash the implementation. Making #\:
reserved
works against this.
First, if the character is not reserved, then I cannot use it for anything
special in my implementation and remain compatible with the outside world.
Secondly, suppose that I use some other character, not currently legal in
identifiers, such as ``#''. Then you probably *still* can't read my code
into your implementation, since your reader will either barf at my uses of
the illegal character or, even worse, silently parse the code making some
entirely different implementation-specific interpretation of the character.
Thus, no matter how this issue goes, you probably can't trivially parse my
code in your implementation. Your argument is therefore moot.
Ken's message ended with the following line:
(mod1:foo 3 x mod2:bar) --> ((*value mod1 'foo) 3 x (*value mod2 bar))
This might be true in some T-like interpretation of structured names, but
since I reject first-class environments (on the basis of large program
robustness and the value of static checking), I cannot use such a
rewriting. Besides, it's appallingly verbose and unreadable for a
construct to be so commonly used. One might as well force us to say (quote
...) everywhere instead of the simpler ``lexical convention''.
Jim Miller suggests that I use ``|'' instead of colon. I considered it,
but found it less readable and far less culturally compatible than colon.
It seems silly to diverge from Common Lisp and Zetalisp on this convention
for so little reason. After all, how much code would have to change if we
reserved colon? None, since most implementations could simply choose to
``experiment'' with colon by allowing in identifiers, just as they do now.
Remember Alan's best point: this only affects the definition of what
programs are portable and does not force any implementation to change at
all.
Pavel
∂05-Jul-89 2048 @mc.lcs.mit.edu:Pavel.pa@xerox.com Assignment to standard variables
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89 20:48:09 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26499;
5 Jul 89 23:45 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 5 Jul 89 23:38:15 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa26423; 5 Jul 89 23:36 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUL 89 20:04:43 PDT
Date: Wed, 05 Jul 89 20:04:36 PDT
From: Pavel.pa@xerox.com
Subject: Assignment to standard variables
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890705-200443-7674@Xerox>
The majority of responses recently have been to my proposal that it be an
error to assign to the standard variables, present in the so-called
``initial environment''.
Jinx's first message on this topic stated his opposition to the proposal on
the grounds that ``the user takes precedence over the system'', the meaning
of which he clarified in a subsequent message. There, he says:
... the system/implementation is a
tool for the user, and as such it should accomodate the wishes of the
user, not viceversa. Thus if a user wants to call CAR something he
writes/uses (in a Church pair implmentation, for example), he should
be allowed to do so.
I have two counterarguments to this. First, since the user cannot portably
assign to (or even rebind) variables named ``if'', ``or'', ``delay'', or
even ``unquote'' (uses of which cannot conflict with its assigned meaning),
the user has already lost this battle.
Second, I question the whole notion of ``user''. Your usage (and that of
most of the other respondents) implies that there is some human,
interactively manipulating the state of some Scheme implementation. This
vision of Scheme implementations is not universal. In particular, it is
easy for me to imagine Scheme systems with many ``users'' and none at all.
In a large system, simultaneously running the code of many programmers,
each of those hackers is a ``user'' in the sense that you mean. For any
one of them to decide to change the value of a standard variable would very
likely be disastrous for all of the others.
This is the value of lexical scoping. It is not necessary for that one
iconoclastic user to make an assignment to CAR; they can simply rebind that
name over the scope of their piece of code. That way, they're happy
because they can use what they see as intuitive names, and the other users
are happy because the standard variables have the predicted standard
values.
With things as they are, you cannot afford to load any code I might send
you into your running system; I might very well make every other
``user-level'' piece of code bomb completely.
The model of a single Scheme programmer sitting at his read-eval-print loop
running only his own small program cannot be the sole customer of this
language design, or else Scheme deserves the occasional claim that it is
but a ``toy'' language. If this is the goal of the bulk of the RRRS
authors, then please let me know; I'll go quietly. I sincerely hope it is
not.
Jinx also mentioned the use of declarations to allow compilers to process
uses of standard variables more efficiently. One should not have to work
in a modified language semantics in order to get reasonable efficiency. In
particular, it seems odd to resort to such semantically inconsistent
constructs just to retain the dubious right to assign to CAR.
In his second message, Jinx offered a ``pragmatic'' reason for opposing my
proposal:
Presumably you would like
implementations to be able to add new primitives to the language
described in the report. Given that the semantics of any programs
using them might be compromised in the same way that it would be when
using a "standard" primitive, you would disallow assignment and
redefinition of implementation-specific primitives as well. This
implies that portability can only be achieved by using obscure names
(ie G00034), since any "reasonable" name is potentially reserved by
some implementation.
R4RS already requires, in section 1.3.1, that every implementation provide
a ``syntactic mode that preempts no lexical conventions of this report and
reserves no identifiers'' other than those listed in the report. Such a
mode is explicitly included to ``support portable code''.
Morry Katz, in contrast, appears to be closer to supporting my proposal.
In his June 28 message on the subject, he says:
You did not request that an implementation be allowed to prohibit
redefinition of the primitives, but stated that you wanted redefinition
of a primitive to be an error.
He also says:
If you would like to propose something that allows your system to
consider redefinition an error but does not require my system
to do such, I might be willing to consider it.
When we state that a certain situation ``is an error'', we state that the
effect of achieving that situation is unspecified. In particular, if we
state that assigning to standard variables is an error, the effect in one
implementation might be that the assignment takes place without difficulty.
In another, an error might be signalled. In another, the compiler might
reject the program, noticing that the assignment expression cannot be
performed without signalling an error. The phrase ``is an error''
encompasses all of these possibilities. Thus, when I ask that we make
assignment to standard variables an error, I am, indeed, proposing
``something that allows [my] system to consider redefinition an error but
does not require [your] system to do such.'' This is the point I was
trying to make in my previous message on this topic. I was not attempting
to pervert Morry's meaning at all.
Morry also mentions declarations:
Nearly everyones compiler currently allows a compiler directive to the
effect
that primitives should be considered immutable and therefore
inlineable. This
has been done for the obvious efficiency reasons and does not require
that the
language specification be altered to always prohibit modifying
primitives.
It is to me a sign of the weakness of the current specification that
``nearly everyone'' feels the need to restrict the semantics in order to
generate reasonable code.
Pavel
∂05-Jul-89 2227 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #153
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89 22:27:50 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27565;
6 Jul 89 1:09 EDT
Date: 6 JUL 89 00:09:35 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #153
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907060109.aa27565@mintaka.lcs.mit.edu>
Scheme Digest #153 6 JUL 89 00:09:35 EDT
Today's Topics:
OOP in Scheme (serious example)
----------------------------------------------------------------------
Date: 5 Jul 89 21:47:32 GMT
From: Brian of ASTD-CP <brian@topaz.rutgers.edu>
Subject: OOP in Scheme (serious example)
Message-Id: <1412@jato.Jpl.Nasa.Gov>
; This'll be my last submission on this topic, so I promise I won't
; be burning up the wires with any more. I thought a serious
; example would be of some interest, however, so here is a FIFO
; queue data type. I'll be building classes for priority queues,
; heaps, splay trees, and assorted others, as well as a data flow
; executive. Anyone interested further in this topic may feel
; free to e-mail me. Again, sorry for the length of these sub-
; missions. BCB.
;================================================================
;| Brian Beckman | brian@topaz.jpl.nasa.gov |
;| Mail Stop 510-202 | (818) 397-9207 |
;| Jet Propulsion Laboratory | |
;| Pasadena, CA 91109 | 3 July 1989 |
;================================================================
;;; Adapted from Abelson & Sussman, Ch. 3, Pg 208 ff.
;;; Uses the ``methods'' OOP package. This is an expanded,
;;; industrial-strength solution to Exercise 3.22 of A & S.
(define (new-queue . initial-list)
(let ( (q (cons () ()))
(dummy (if (not (null? initial-list))
(set! initial-list (car initial-list))))
(supers ()) )
(define (head) (car q))
(define (tail) (cdr q))
(define (set-head! item) (set-car! q item))
(define (set-tail! item) (set-cdr! q item))
(define (empty-queue?) (null? (head)))
(define (front)
(if (send self 'empty?)
(error "FRONT called on empty queue")
(car (head))))
(define (insert-queue! item)
(let ((elt (cons item ()))) ; could be (list item)
(cond
( (send self 'empty?)
(set-head! elt)
(set-tail! elt)
self )
( else
(set-cdr! (tail) elt)
(set-tail! elt)
self ))))
(define (insert-list! lyst)
(cond
( (null? lyst) self )
( else
(send self 'insert! (car lyst))
(insert-list! (cdr lyst)) )))
(define (remove-queue!)
(cond
( (send self 'empty?)
(error "REMOVE called on empty queue") )
( else
(set-head! (cdr (head))) self)))
(define (clear-queue!)
(set! q (cons () ()))
self)
(define (print) (display (head)) (newline))
(define (self msg)
(cond
( (eq? msg 'insert!) insert-queue! )
( (eq? msg 'empty?) empty-queue? )
( (eq? msg 'remove!) remove-queue! )
( (eq? msg 'clear!) clear-queue! )
( (eq? msg 'front) front )
( (eq? msg 'print) print )
( (eq? msg 'list) (lambda () (head)) )
( (eq? msg 'insert-list!) insert-list! )
( (search-supertypes supers msg) )
( else (make-error-method "Queue" msg) )))
(insert-list! initial-list) ;;; returns ``self''
))
;;; end of new-queue
; Test suite for queues.
(define q (new-queue '(a b c d e)))
(send q 'print)
(send q 'list)
(send (send q 'remove!) 'print)
(send q 'empty?)
(send (send q 'clear!) 'empty?)
(send q 'print)
(define q (new-queue))
(send q 'empty?)
------------------------------
End of Scheme Digest
********************
∂05-Jul-89 2230 @mc.lcs.mit.edu:Pavel.pa@xerox.com Fluid binding
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89 22:30:19 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27623;
6 Jul 89 1:12 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Jul 89 00:46:48 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa27183; 6 Jul 89 0:44 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUL 89 21:05:34 PDT
Date: Wed, 05 Jul 89 21:05:31 PDT
From: Pavel.pa@xerox.com
Subject: Fluid binding
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890705-210534-7725@Xerox>
In conversations with several other members of this group, it has been
mentioned that there really isn't very much disagreement any longer on the
issue of fluid binding; it is usually noted that we simply need a concrete
proposal on which to agree. On this optimistic assumption, therefore, I
offer the following.
I hope that we can agree on the following points concerning fluid binding:
-- We want some kind of facility in the language that supports a form of
dynamic binding.
-- We do not want a Common Lisp-style two-namespace solution.
-- The binding construct has a syntax something like LET, in which a set of
expressions are evaluated in an unspecified order and their values used in
establishing new fluid bindings.
-- The extent of those bindings is dynamic, in the sense that they are in
effect exactly during the evaluation of the body of the binding form.
-- As a consequence, continuations created in that body should capture the
fluid environment and re-establish it upon invocation. Such
re-establishment should not involve re-evaluating the non-body expressions
in the binding form.
-- Upon exit from the body of the binding form, the bindings in effect
before entry to the form should be restored.
One of the most commonly-cited proposals for such a facility is described,
for example, in Kent Dybvig's book. In that facility, the so-called
``binding form'' in fact creates no bindings at all. Instead, it saves the
current values of the named lexically-visible variables, assigns new values
during the evaluation of the body, and restores the old ones after the body
is finished. This could be described implementationally as ``shallow
binding lexical variables''.
There are some problems with this idea for some implementations.
In a time-shared multiprocessing implementation, on each context switch the
set of bindings for each of the old and new running process must be
re-traversed, in order to properly save the old context and re-establish
the new.
Further, if two processes share a continuation, then one would expect that
when they share the captured fluid environment they also share the
``state'' of those bindings. For example, if a process fluid-binds a
particular variable, captures the continuation, modifies the variable, and
then forks a process invoking the newly-created continuation, I would hope
that the new process would ``see'' the new value of the shared fluid
binding. Of course, the two processes should also be able to communicate
by repeated assignments to the shared binding. I do not see how to
implement this.
Matters are even worse for a multiprocessor implementation (that is,
multiple instruction single data, such as on a Sequent or other
shared-memory multiprocessor). In this case, I can see no way to avoid the
use of deep binding to get the desired semantics. In a shallow bound
implementation, multiple processes will ``race'' for ``rebinding'' a shared
variable and ultimately lose horribly.
Given that some implementations will be forced to use deep binding, we
could simply consider using the same syntax and semantics as before, but
with a deep binding implementation. In such a situation, if a particular
variable might at some point be fluid-bound, then all references (both read
and write) would have to invoke the deep binding lookup mechanism. Since
this would, of necessity, include all global variables (since a compiler
can never claim to have seen all uses of a global variable, it must assume
the worst), I conclude that the performance degradation would be
unacceptable. (There are ways to make this a little better, such as adding
a bit to each such variable to say whether or not it has ever been
fluid-bound. If not, then the value must be in the global cell and the
expensive lookup can be avoided. It still sounds too slow to me.)
The problem here is that references to fluid-bound variables cannot, in
general, be lexically distinguished from references to non-fluid-bound
variables. My proposal, therefore, makes such a distinction, in a sense.
Having motivated the design, I now present it.
=========
(MAKE-FLUID obj) [Procedure]
Create and return a new ``fluid variable'' whose global value is obj.
(FLUID-REF fluid-variable) [Procedure]
Return the value of the given fluid-variable in the current fluid
environment.
(FLUID-SET! fluid-variable obj) [Procedure]
Change the value of the given fluid-variable in the current fluid
environment. The returned value is unspecified.
(FLUID-LET ((var-expr val-expr) ...) body) [Syntax]
Evaluate the var-exprs and val-exprs in an unspecified order; the var-exprs
should yield fluid variables. Return the value of the body in a new,
nested fluid environment in which the given fluid variables have new
bindings, initialized to the given values. This fluid environment has
precisely the same extent as the evaluation of the body and is thus
captured by continuations created within the body and re-established by
those continuations on invocation.
=========
The implementation is free to adopt either shallow or deep binding. In
either case, a ``fluid variable'' is simply a one-cell allocated datum
containing the value of the fluid variable either in the current fluid
environment (shallow binding) or in the global, top-level fluid environment
(deep binding). In either case, the address of the cell can be used as the
``identifier'' for the variable in the environment. This proposal, in
comparison to the one discussed before, increases the cost per reference in
a shallow-bound implementation by one memory reference, indirecting through
the cell-address. This seems a small price to pay.
The proposal is unusual in that the variable position in FLUID-LET is
evaluated, but I anticipate that in almost all uses the expression will be
a simple lexical variable reference:
(define *foo* (make-fluid 7))
(fluid-let ((*foo* 8))
(+ (fluid-ref *foo*) 1))
=> 9
Comments?
Pavel
∂05-Jul-89 2240 @mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu Assignment to standard variables
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89 22:40:01 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27843;
6 Jul 89 1:21 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Jul 89 01:17:50 EDT
Received: from [18.43.0.171] by mintaka.lcs.mit.edu id aa27680;
6 Jul 89 1:14 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Thu, 6 Jul 89 01:11:35 edt
Date: Thu, 6 Jul 89 01:11:35 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8907060511.AA28668@ZURICH.AI.MIT.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Wed, 05 Jul 89 20:04:36 PDT <890705-200443-7674@Xerox>
Subject: Assignment to standard variables
I have two counterarguments to this. First, since the user cannot portably
assign to (or even rebind) variables named ``if'', ``or'', ``delay'', or
even ``unquote'' (uses of which cannot conflict with its assigned meaning),
the user has already lost this battle.
We've been trying to fix this for quite a while. It has not been
fixed in R4RS because of political and technical problems having to do
with the actual solutions suggested, not because we don't agree that
this should be fixed.
Second, I question the whole notion of ``user''. Your usage (and that of
most of the other respondents) implies that there is some human,
interactively manipulating the state of some Scheme implementation. This
vision of Scheme implementations is not universal. In particular, it is
easy for me to imagine Scheme systems with many ``users'' and none at all.
In a large system, simultaneously running the code of many programmers,
each of those hackers is a ``user'' in the sense that you mean. For any
one of them to decide to change the value of a standard variable would very
likely be disastrous for all of the others.
You misunderstand my argument in many ways:
1) By user I mean any programmer, not necessarily human. I would like
my program generating programs not to have to probe the underlying
implementation for the list of all unusable names, which is likely to
evolve as the implementation and the language evolve. Furthermore, I
would like not to have to rewrite my programs when/if R5RS comes out
just because a new procedure has been added to the report.
2) Redefinition does not imply assignment. In a scheme system with
first class environments, each user can get his own (initially
identical) first class environment in which he can redefine as he
pleases, without affecting anyone else. [This is what I consider
essential. I would not be terribly upset if we disallowed
(set! car ...) but would not tolerate disallowing (define car ...).]
Note that my position does not require first class environments, it
simply requires that each user's interactive environment be isolated
from what the system uses, and from what other users use if there are
multiple users. As I mentioned in another message, security of the
implementation is an implementation problem, not a language problem.
3) Even assignment of shared variables should be legal. Assignment of
shared variables is a double edged sword: It is potentially dangerous
(like anything powerful), but if used judiciously it provides a
wonderful way of debugging and patching running systems.
Think of the following analogy:
The environment tree is like a hierarchical file system (with path
inheritance). Each user has his own "home directory" where he can
name any file anything he wants, although shadowing the name where a
system provided utility resides may be inconvenient. On the other
hand, s/he can fix a bug in the C compiler (for example) by replacing
(assigning) the current file containing it. Operating systems need
the ability to replace system utilities because they are intended to
run for long periods of time and allow incremental patches. Please
don't remove such an ability from my favorite operating system! Your
suggestion would make Scheme too inflexible for long running evolving
applications.
This is the value of lexical scoping. It is not necessary for that one
iconoclastic user to make an assignment to CAR; they can simply rebind that
name over the scope of their piece of code. That way, they're happy
because they can use what they see as intuitive names, and the other users
are happy because the standard variables have the predicted standard
values.
Lexical scoping as it appears in the report does not solve the
problem. The top level environment allows me some debugging ability
(through interaction) which I don't have when I use any other
mechanism. If your implementation provides interaction (with
definition) in arbitrary environments, your implementation can solve
the isolation problem trivially.
Jinx also mentioned the use of declarations to allow compilers to process
uses of standard variables more efficiently. One should not have to work
in a modified language semantics in order to get reasonable efficiency. In
particular, it seems odd to resort to such semantically inconsistent
constructs just to retain the dubious right to assign to CAR.
Reasonable is a subjective term. I think it is perfectly possible to
obtain reasonable efficiency without declarations. Efficiency beyond
this may require concessions, and declarations are a small price to
pay. I would like to see a compiler that provides complete security,
complete debugability, and utmost efficiency without any form of
declaration, but I have not yet seen such a beast (nor do I think it
is possible to have one on stock hardware).
Again, although I think that the right to assign to CAR is important,
the one that I'm more concerned with is the right to DEFINE CAR. You
are viewing definition and assignment as the same thing, but in my
mind (and in the implementation that I use) they are not. If your
implementation and development environment are confused about this,
that's your implementor's problem, but please don't impose these
limitations on the language or my implementation.
You also seem to have shifted your argument from semantic
predictability to efficiency, and efficiency has never been important
when designing Scheme. The problem with efficiency as an argument in
language design is that it is a time dependent parameter, since it
depends on compilation technology and hardware, both of which change
quickly. Would you make the same efficiency argument about MAP that
you are making about CAR? What about LIST-TAIL or
CALL-WITH-CURRENT-CONTINUATION? Yet if I'm playing with streams I
would like to define MAP, and if I'm playing with interpreters I may
want to redefine CALL-WITH-CURRENT-CONTINUATION. In all but contrived
situations the efficiency lost from not open coding MAP or
CALL-WITH-CURRENT-CONTINUATION is minimal, so your efficiency argument
does not really stand up.
R4RS already requires, in section 1.3.1, that every implementation provide
a ``syntactic mode that preempts no lexical conventions of this report and
reserves no identifiers'' other than those listed in the report. Such a
mode is explicitly included to ``support portable code''.
I think most people would agree that R4RS as it currently stands is a
toy language. Besides macros, fluid binding and other well known
conveniences, it lacks any practical way of separating large programs
into semi-independent subprograms without exporting zillions of names
into the top level environment.
I think most implementations provide some way of solving or bypassing
these problems. Thus, until we solve these issues, R4RS is unusable
for large programs, and your argument doesn't help me at all.
Some day in the future, when we solve (if we can ever agree on
anything else) these problems, this may be an option, but almost any
facility that I can envision for separating and combining subprograms
will allow me to have my own definitions of anything I want.
I'm afraid we are going to disagree very strongly on this issue, and
therefore we are at an impasse. Unfortunately that seems to be
happening with everything else that anyone proposes, so I'm afraid
that R3.95RS is the end of the line. What a pity.
∂06-Jul-89 0713 @MC.lcs.mit.edu:jmiller@crl.dec.com Reserving a character for experimentation
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89 07:13:39 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03520;
6 Jul 89 10:09 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Jul 89 10:04:27 EDT
Received: from [128.45.9.1] by mintaka.lcs.mit.edu id aa03471;
6 Jul 89 10:02 EDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
id AA09772; Thu, 6 Jul 89 07:01:41 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
for rrrs-authors@mc.lcs.mit.edu; id AA09772; Thu, 6 Jul 89 07:01:41 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
id AA06722; Thu, 6 Jul 89 10:02:56 EDT
Date: Thu, 6 Jul 89 09:59:48 EDT
From: jmiller@crl.dec.com
Message-Id: <8907061359.AA00613@peanut.DEC.COM>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@MC.lcs.mit.edu
In-Reply-To: 5-Jul-89 1904 PDT's message of Wed, 5 Jul 89 22:49:11 EDT <8907060249.AA06354@crl.crl.dec.com>
Subject: Reserving a character for experimentation
Reply-To: JMiller@crl.enet.dec.com
Sorry, but I can't really see a valid argument for taking a character
already in use (not just presumably, but actually) in existing Scheme
code and reserving it because you prefer it over other choices already
available. I'm not a fan of lexical syntax, and I think the damage
caused to existing (possibly portable) code outweighs the possible
gains.
I don't understand the following comment:
After all, how much code would have to change if we reserved
colon? None, since most implementations could simply choose to
``experiment'' with colon by allowing in identifiers, just as
they do now.
It appears to me that this simply isn't true. Portable code would not
be permitted to use names with embedded colons, and such code already
exists. Perhaps what you meant is that no individual's code running
in an existing implementation would be affected -- but I'm more
worried about the portable code I've written over the years. I'd like
it to remain portable, and your suggesting one more headache to worry
about.
--Jim
P.S.: Another pair of suggestions, valid within the existing
framework. Other ideas along this line that would be more extensible
would be very interesting.
(module#:submodule#:procedure ...)
(procedure #!part-of submodule #!part-of module ...)
∂06-Jul-89 0730 @MC.lcs.mit.edu:sfk@hplb.hpl.hp.com Re: Fluid binding
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89 07:30:48 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03706;
6 Jul 89 10:24 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Jul 89 10:20:31 EDT
Received: from hplb.hpl.hp.com by mintaka.lcs.mit.edu id aa03567;
6 Jul 89 10:14 EDT
Received: from sknight.hpl.hp.com by hplb; Thu, 6 Jul 89 15:04:42 bst
Message-Id: <8907061404.AA28845@otter.hpl.hp.com>
Received: by sknight; Thu, 6 Jul 89 15:01:12 bst
From: Steve Knight <sfk@hplb.hpl.hp.com>
Subject: Re: Fluid binding
To: Pavel.pa@xerox.com
Date: Thu, 6 Jul 89 15:01:09 BST
Cc: rrrs-authors@MC.lcs.mit.edu
In-Reply-To: <890705-210534-7725@Xerox>; from "Pavel.pa@xerox.com" at Jul 05, 89 9:05 pm
X-Mailer: Elm [version 2.0 beta]
Re: Fluid Binding
An effective approach to fluid binding is dynamic localisation of arbitrary
expressions, exemplified by the "dlocal" construct of Pop11. The idea is to
permit the localisation of any expression & fluid binding drops out as a
special case.
The general construct might be [I'm not suggesting this syntax]..
(dlocal
(
( save-expression entry-action exit-action )
( save-expression entry-action exit-action )
...
)
body
)
and the code generated for
(let-fluid
((x E))
body
)
would expand into
(dlocal
( ( x ; save
(set! x E) ; entry
(set! x (saved)) ; exit, with the "saved" form
)
)
body ; sequence of expressions
)
It would then be possible to do things like localise the "car" of a pair.
eg.
(dlocal
( ( (car x) ; save
(set-car! x E) ; entry-action
(set-car! x (saved)); exit-action
)
)
...
)
In Pop11 there is an association between access procedures such as "car" and
the update procedure "set-car!" ; namely an operation called "updater" which
maps "car" into "set-car!". Because of that, it is possible to write dlocal
expressions more elegantly as
(dlocal
( (save-expression update-value)
...
)
body
)
So the dynamic localisation of the "car" of a list would be
(dlocal
( ((car x) E)
...
)
)
The common case of localising a variable could be done by simply allowing a
third form for that.
(dlocal
( (variable E)
...
)
...
)
Putting these cases together, here is a piece of code that localises the
variable "x", the car of the list "y", and closes the output-port "z" on exit.
(dlocal
( (x Ex)
((car y) Ey)
(nil nil (close-output-port z))
)...
)
An interesting issue is deciding how dynamic localisation interacts with
continuations. In Pop11, the default solution is to run local-actions on
continuation activation. However it is possible to determine whether the
local-action is being run because of a continuation swap or a procedure exit.
Determining the right solution for Scheme would require careful thought.
Steve Knight
∂06-Jul-89 0843 @mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu Fluid binding
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89 08:43:46 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04606;
6 Jul 89 11:42 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Jul 89 11:37:54 EDT
Received: from [18.43.0.171] by mintaka.lcs.mit.edu id aa04479;
6 Jul 89 11:31 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Thu, 6 Jul 89 11:28:47 edt
Date: Thu, 6 Jul 89 11:28:47 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8907061528.AA01541@ZURICH.AI.MIT.EDU>
To: sfk@hplb.hpl.hp.com
Cc: Pavel.pa@xerox.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Steve Knight's message of Thu, 6 Jul 89 15:01:09 BST <8907061404.AA28845@otter.hpl.hp.com>
Subject: Fluid binding
Pop11s dlocal is the analogous of dynamic-wind, a utility available in
some Scheme implementations.
A "shallow bound" implementation of fluid-let can easily be built on
top of dynamic-wind by expanding
(fluid-let ((foo <value>))
<code>)
into
(let ((dummy <value>))
(dynamic-wind
(lambda ()
(let ((outside foo))
(set! foo dummy)
(set! dummy outside)))
(lambda ()
<code>)
(lambda ()
(let ((inside foo))
(set! foo dummy)
(set! dummy inside)))))
Unfortunately this does not work well on shared memory multiprocessors,
as Pavel pointed out.
∂06-Jul-89 1012 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu Assignment to standard variables
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89 10:12:40 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05654;
6 Jul 89 13:04 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Jul 89 12:38:24 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa05358;
6 Jul 89 12:32 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA25682; Thu, 6 Jul 89 09:31:39 PDT
Date: Thu, 6 Jul 89 09:31:39 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907061631.AA25682@sesame.Stanford.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Wed, 05 Jul 89 20:04:36 PDT <890705-200443-7674@Xerox>
Subject: Assignment to standard variables
Date: Wed, 05 Jul 89 20:04:36 PDT
From: Pavel.pa@xerox.com
The majority of responses recently have been to my proposal that it be an
error to assign to the standard variables, present in the so-called
``initial environment''.
Jinx's first message on this topic stated his opposition to the proposal on
the grounds that ``the user takes precedence over the system'', the meaning
of which he clarified in a subsequent message. There, he says:
... the system/implementation is a
tool for the user, and as such it should accomodate the wishes of the
user, not viceversa. Thus if a user wants to call CAR something he
writes/uses (in a Church pair implmentation, for example), he should
be allowed to do so.
I have two counterarguments to this. First, since the user cannot portably
assign to (or even rebind) variables named ``if'', ``or'', ``delay'', or
even ``unquote'' (uses of which cannot conflict with its assigned meaning),
the user has already lost this battle.
This is one of the reasons we need macros. As soon as we have them, I will be
able to override the default definitions for special forms as well.
Second, I question the whole notion of ``user''. Your usage (and that of
most of the other respondents) implies that there is some human,
interactively manipulating the state of some Scheme implementation. This
vision of Scheme implementations is not universal. In particular, it is
easy for me to imagine Scheme systems with many ``users'' and none at all.
In a large system, simultaneously running the code of many programmers,
each of those hackers is a ``user'' in the sense that you mean. For any
one of them to decide to change the value of a standard variable would very
likely be disastrous for all of the others.
I would suggest that in such an environment each of the users should have their
REP loop executing in a separate binding environment in which all of the Scheme
primitives are bound. When a user rebinds a primitive in this type of
environment structure, they only effect themselves. If you have a module
package (as I believe you want), a user who has rebound a primitive could get
back the original definition by looking it up in some (possibly immutable in
your implementation) system environment/module.
This is the value of lexical scoping. It is not necessary for that one
iconoclastic user to make an assignment to CAR; they can simply rebind that
name over the scope of their piece of code. That way, they're happy
because they can use what they see as intuitive names, and the other users
are happy because the standard variables have the predicted standard
values.
With things as they are, you cannot afford to load any code I might send
you into your running system; I might very well make every other
``user-level'' piece of code bomb completely.
(See above, not true)
The model of a single Scheme programmer sitting at his read-eval-print loop
running only his own small program cannot be the sole customer of this
language design, or else Scheme deserves the occasional claim that it is
but a ``toy'' language. If this is the goal of the bulk of the RRRS
authors, then please let me know; I'll go quietly. I sincerely hope it is
not.
Jinx also mentioned the use of declarations to allow compilers to process
uses of standard variables more efficiently. One should not have to work
in a modified language semantics in order to get reasonable efficiency. In
particular, it seems odd to resort to such semantically inconsistent
constructs just to retain the dubious right to assign to CAR.
You cloud this issue by placing your value judgements on the rebinding of
primitves by refering to our desire to do such as of "dubious" value. What we
are really discussing is what should be the default semantics. If your
semantics were the default then I would require a declaration to enable
rebinding of primitives. I happen to feel that this second polarity ios less
elegant; but, you would obviously disagree. At the risk of offending the faint
of heart, I would point out that many systems also have type declarations to
improve compilation efficiency; however, I doubt many people would state that
Scheme should always require type information be supplied in all constructs in
order to avoid anyone ever having to use such declarations.
In his second message, Jinx offered a ``pragmatic'' reason for opposing my
proposal:
Presumably you would like
implementations to be able to add new primitives to the language
described in the report. Given that the semantics of any programs
using them might be compromised in the same way that it would be when
using a "standard" primitive, you would disallow assignment and
redefinition of implementation-specific primitives as well. This
implies that portability can only be achieved by using obscure names
(ie G00034), since any "reasonable" name is potentially reserved by
some implementation.
R4RS already requires, in section 1.3.1, that every implementation provide
a ``syntactic mode that preempts no lexical conventions of this report and
reserves no identifiers'' other than those listed in the report. Such a
mode is explicitly included to ``support portable code''.
Morry Katz, in contrast, appears to be closer to supporting my proposal.
In his June 28 message on the subject, he says:
You did not request that an implementation be allowed to prohibit
redefinition of the primitives, but stated that you wanted redefinition
of a primitive to be an error.
He also says:
If you would like to propose something that allows your system to
consider redefinition an error but does not require my system
to do such, I might be willing to consider it.
When we state that a certain situation ``is an error'', we state that the
effect of achieving that situation is unspecified. In particular, if we
state that assigning to standard variables is an error, the effect in one
implementation might be that the assignment takes place without difficulty.
In another, an error might be signalled. In another, the compiler might
reject the program, noticing that the assignment expression cannot be
performed without signalling an error. The phrase ``is an error''
encompasses all of these possibilities. Thus, when I ask that we make
assignment to standard variables an error, I am, indeed, proposing
``something that allows [my] system to consider redefinition an error but
does not require [your] system to do such.'' This is the point I was
trying to make in my previous message on this topic. I was not attempting
to pervert Morry's meaning at all.
You have grossly misrepresented my position (albeit probably by accident). I
believe that anything which is described by "is an error" in the report to be a
violation of Scheme. To have the semantics which I believe are correct be
described as "is an error" is COMPLETELY unsatisfactory to me. I suggest that
we, as a community, work harder on agreeing on some module system. This would
allow us to agree on the name a module in which all of the primitives would be
bound to implementations of the semantics specified in RNRS. Users who wanted
to guarantee that the values of the primitves never changed could reference
them in this module.
Morry also mentions declarations:
Nearly everyones compiler currently allows a compiler directive to the
effect
that primitives should be considered immutable and therefore
inlineable. This
has been done for the obvious efficiency reasons and does not require
that the
language specification be altered to always prohibit modifying
primitives.
It is to me a sign of the weakness of the current specification that
``nearly everyone'' feels the need to restrict the semantics in order to
generate reasonable code.
Pavel
(see above)
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂06-Jul-89 1035 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu Fluid binding
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89 10:34:39 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05813;
6 Jul 89 13:15 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Jul 89 12:44:59 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa05480;
6 Jul 89 12:41 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA25714; Thu, 6 Jul 89 09:41:08 PDT
Date: Thu, 6 Jul 89 09:41:08 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907061641.AA25714@sesame.Stanford.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Wed, 05 Jul 89 21:05:31 PDT <890705-210534-7725@Xerox>
Subject: Fluid binding
Date: Wed, 05 Jul 89 21:05:31 PDT
From: Pavel.pa@xerox.com
In conversations with several other members of this group, it has been
mentioned that there really isn't very much disagreement any longer on the
issue of fluid binding; it is usually noted that we simply need a concrete
proposal on which to agree. On this optimistic assumption, therefore, I
offer the following.
I hope that we can agree on the following points concerning fluid binding:
-- We want some kind of facility in the language that supports a form of
dynamic binding.
-- We do not want a Common Lisp-style two-namespace solution.
-- The binding construct has a syntax something like LET, in which a set of
expressions are evaluated in an unspecified order and their values used in
establishing new fluid bindings.
-- The extent of those bindings is dynamic, in the sense that they are in
effect exactly during the evaluation of the body of the binding form.
-- As a consequence, continuations created in that body should capture the
fluid environment and re-establish it upon invocation. Such
re-establishment should not involve re-evaluating the non-body expressions
in the binding form.
-- Upon exit from the body of the binding form, the bindings in effect
before entry to the form should be restored.
One of the most commonly-cited proposals for such a facility is described,
for example, in Kent Dybvig's book. In that facility, the so-called
``binding form'' in fact creates no bindings at all. Instead, it saves the
current values of the named lexically-visible variables, assigns new values
during the evaluation of the body, and restores the old ones after the body
is finished. This could be described implementationally as ``shallow
binding lexical variables''.
There are some problems with this idea for some implementations.
In a time-shared multiprocessing implementation, on each context switch the
set of bindings for each of the old and new running process must be
re-traversed, in order to properly save the old context and re-establish
the new.
Further, if two processes share a continuation, then one would expect that
when they share the captured fluid environment they also share the
``state'' of those bindings. For example, if a process fluid-binds a
particular variable, captures the continuation, modifies the variable, and
then forks a process invoking the newly-created continuation, I would hope
that the new process would ``see'' the new value of the shared fluid
binding. Of course, the two processes should also be able to communicate
by repeated assignments to the shared binding. I do not see how to
implement this.
Matters are even worse for a multiprocessor implementation (that is,
multiple instruction single data, such as on a Sequent or other
shared-memory multiprocessor). In this case, I can see no way to avoid the
use of deep binding to get the desired semantics. In a shallow bound
implementation, multiple processes will ``race'' for ``rebinding'' a shared
variable and ultimately lose horribly.
Given that some implementations will be forced to use deep binding, we
could simply consider using the same syntax and semantics as before, but
with a deep binding implementation. In such a situation, if a particular
variable might at some point be fluid-bound, then all references (both read
and write) would have to invoke the deep binding lookup mechanism. Since
this would, of necessity, include all global variables (since a compiler
can never claim to have seen all uses of a global variable, it must assume
the worst), I conclude that the performance degradation would be
unacceptable. (There are ways to make this a little better, such as adding
a bit to each such variable to say whether or not it has ever been
fluid-bound. If not, then the value must be in the global cell and the
expensive lookup can be avoided. It still sounds too slow to me.)
The problem here is that references to fluid-bound variables cannot, in
general, be lexically distinguished from references to non-fluid-bound
variables. My proposal, therefore, makes such a distinction, in a sense.
To the best of my recolection, all of these problems were adequately addressed
in a solution to this problem of fluid-let for multiprocessors deveoloped at a
meeting between the MIT CScheme community and the BBN Butterfly Scheme group
about 3 years ago. Again straining my memory, I seem to recall that most of
the good ideas came from Chris Hansen, so we should probably ask him to refresh
our collective memories as to his solution.
Having motivated the design, I now present it.
=========
(MAKE-FLUID obj) [Procedure]
Create and return a new ``fluid variable'' whose global value is obj.
(FLUID-REF fluid-variable) [Procedure]
Return the value of the given fluid-variable in the current fluid
environment.
(FLUID-SET! fluid-variable obj) [Procedure]
Change the value of the given fluid-variable in the current fluid
environment. The returned value is unspecified.
(FLUID-LET ((var-expr val-expr) ...) body) [Syntax]
Evaluate the var-exprs and val-exprs in an unspecified order; the var-exprs
should yield fluid variables. Return the value of the body in a new,
nested fluid environment in which the given fluid variables have new
bindings, initialized to the given values. This fluid environment has
precisely the same extent as the evaluation of the body and is thus
captured by continuations created within the body and re-established by
those continuations on invocation.
=========
The implementation is free to adopt either shallow or deep binding. In
either case, a ``fluid variable'' is simply a one-cell allocated datum
containing the value of the fluid variable either in the current fluid
environment (shallow binding) or in the global, top-level fluid environment
(deep binding). In either case, the address of the cell can be used as the
``identifier'' for the variable in the environment. This proposal, in
comparison to the one discussed before, increases the cost per reference in
a shallow-bound implementation by one memory reference, indirecting through
the cell-address. This seems a small price to pay.
The proposal is unusual in that the variable position in FLUID-LET is
evaluated, but I anticipate that in almost all uses the expression will be
a simple lexical variable reference:
(define *foo* (make-fluid 7))
(fluid-let ((*foo* 8))
(+ (fluid-ref *foo*) 1))
=> 9
Comments?
Pavel
I find this special designation of fluid variables to be quite distasteful. It
would require a much better argument as to the impossibility of doing shallow
binding reasonably on multiprocessors before I would be willing to accept a
proposal of this form.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂06-Jul-89 1043 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu Fluid binding
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89 10:43:46 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06108;
6 Jul 89 13:36 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Jul 89 13:27:30 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa05953;
6 Jul 89 13:21 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA25816; Thu, 6 Jul 89 10:07:31 PDT
Date: Thu, 6 Jul 89 10:07:31 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907061707.AA25816@sesame.Stanford.EDU>
To: sfk@hplb.hpl.hp.com
Cc: Pavel.pa@xerox.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Steve Knight's message of Thu, 6 Jul 89 15:01:09 BST <8907061404.AA28845@otter.hpl.hp.com>
Subject: Fluid binding
From: Steve Knight <sfk@hplb.hpl.hp.com>
Date: Thu, 6 Jul 89 15:01:09 BST
X-Mailer: Elm [version 2.0 beta]
Re: Fluid Binding
An effective approach to fluid binding is dynamic localisation of arbitrary
expressions, exemplified by the "dlocal" construct of Pop11. The idea is to
permit the localisation of any expression & fluid binding drops out as a
special case.
The general construct might be [I'm not suggesting this syntax]..
(dlocal
(
( save-expression entry-action exit-action )
( save-expression entry-action exit-action )
...
)
body
)
and the code generated for
(let-fluid
((x E))
body
)
would expand into
(dlocal
( ( x ; save
(set! x E) ; entry
(set! x (saved)) ; exit, with the "saved" form
)
)
body ; sequence of expressions
)
It would then be possible to do things like localise the "car" of a pair.
eg.
(dlocal
( ( (car x) ; save
(set-car! x E) ; entry-action
(set-car! x (saved)); exit-action
)
)
...
)
In Pop11 there is an association between access procedures such as "car" and
the update procedure "set-car!" ; namely an operation called "updater" which
maps "car" into "set-car!". Because of that, it is possible to write dlocal
expressions more elegantly as
(dlocal
( (save-expression update-value)
...
)
body
)
So the dynamic localisation of the "car" of a list would be
(dlocal
( ((car x) E)
...
)
)
The common case of localising a variable could be done by simply allowing a
third form for that.
(dlocal
( (variable E)
...
)
...
)
Putting these cases together, here is a piece of code that localises the
variable "x", the car of the list "y", and closes the output-port "z" on exit.
(dlocal
( (x Ex)
((car y) Ey)
(nil nil (close-output-port z))
)...
)
An interesting issue is deciding how dynamic localisation interacts with
continuations. In Pop11, the default solution is to run local-actions on
continuation activation. However it is possible to determine whether the
local-action is being run because of a continuation swap or a procedure exit.
Determining the right solution for Scheme would require careful thought.
Steve Knight
MIT Cscheme already has a form which is in many ways similar to DLOCAL. Its
syntax is (dynamic-wind <entry-form> <body> <exit-form>). (I hope I have those
in the correct order!) In the absence of continuations, the entry form is
executed first, followed by the body, followeed by the exit form. The value
returned by dynamic-wind is the value of BODY. If a throw to a continuation
which was captured outside the dynamic scope of a dynamic-wind form takes place
from inside the body of that form, then the exit-form of that dynamic-wind is
executed prior to invoking the continuation. Similarly, if a throw from
outside the dynamic scope of a dynamic-wind form to a continuation captured
while executing body takes place then the entry-form of the given dynamic wind
is reexecuted before the continuation is invoked. As with dlocal, fluid-let
can be built as a macro on top of this verrsion of dynamic-wind.
I do not remember if the semantics of throing into or out of the entry and exit
forms is specified for dynamic-wind. At the moment it is not obvious to me
what the correct semantics are; but, I am interested in anyones suggestions.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂06-Jul-89 1058 @MC.lcs.mit.edu:jinx@ZURICH.ai.mit.edu Fluid binding
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89 10:58:10 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06245;
6 Jul 89 13:47 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Jul 89 13:38:14 EDT
Received: from [18.43.0.171] by mintaka.lcs.mit.edu id aa06027;
6 Jul 89 13:32 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Thu, 6 Jul 89 13:29:39 edt
Date: Thu, 6 Jul 89 13:29:39 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8907061729.AA02296@ZURICH.AI.MIT.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@MC.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Wed, 05 Jul 89 21:05:31 PDT <890705-210534-7725@Xerox>
Subject: Fluid binding
I like your proposal, but I have a some suggestions:
1) MAKE-FLUID, FLUID-REF and FLUID-SET! don't have much to do with
fluids, they have to do with cells (or boxes, as some other people
call them). As such, I would like them to be renamed to
MAKE-CELL, CELL-REF, and CELL-SET!.
Alternatively we could have both MAKE-CELL, CELL-REF, CELL-SET! to
manipulate cells (the selector and mutator always provide the global
value), and FLUID-CELL-REF, FLUID-CELL-SET! to access the current
dynamic value. Which of the accessors is written on top of which
depends on whether the implementation is deep or shallow.
2) Although I admit that FLUID-LET would be the most common way of
obtaining dynamic behavior, I'd rather have it be a simple macro that
expands into a standard procedure. In particular, I would like to
have
(FLUID-LET ((<var-expr1> <val-expr1>) (<var-expr2> <val-expr2>) ... ) <body>)
expand into something like
(with-cell-contents
(list var-expr1 var-expr2 ...)
(list val-expr1 val-expr2 ...)
(lambda ()
<body>))
3) There are many incompatible versions of FLUID-LET out there, so I
think we should use a different name for it so that existing
implementations can continue using their code without having to
rewrite it and can provide two different mechanisms, the standard, and
the old one. I would suggest WITH-FLUID-CONTENTS or something like
that, but I'm not good at choosing names.
4)
Given that some implementations will be forced to use deep binding, we
could simply consider using the same syntax and semantics as before, but
with a deep binding implementation. In such a situation, if a particular
variable might at some point be fluid-bound, then all references (both read
and write) would have to invoke the deep binding lookup mechanism. Since
this would, of necessity, include all global variables (since a compiler
can never claim to have seen all uses of a global variable, it must assume
the worst), I conclude that the performance degradation would be
unacceptable. (There are ways to make this a little better, such as adding
a bit to each such variable to say whether or not it has ever been
fluid-bound. If not, then the value must be in the global cell and the
expensive lookup can be avoided. It still sounds too slow to me.)
It is not necessarily as expensive as you think. Assuming that
implementations have a reasonably cheap way of detecting unbound
variables at run time (perhaps the bit that you mention), you can make
all variables which have fluid values appear to be unbound, and make
the unbound trap handler "discover" that the variable was in fact
bound and fluid. Under these conditions, the cost of accessing a
global variable that has NOT been fluidized does not change, while
accessing one that has becomes a little more expensive, but not too
much if the trap mechanism is reasonably efficient.
I'm not advocating going to this method (it is what Jim Miller's
MultiScheme does), but I think that your objections on the grounds of
performance are not really justified.
∂06-Jul-89 1637 @mc.lcs.mit.edu,@ZURICH.ai.mit.edu:ramsdell@linus.mitre.org An International Character Set for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89 16:37:32 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa10625;
6 Jul 89 19:29 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Jul 89 19:25:20 EDT
Received: from ZURICH.AI.MIT.EDU by mintaka.lcs.mit.edu id aa10560;
6 Jul 89 19:23 EDT
Received: from mbunix.mitre.org ([129.83.20.100]) by ZURICH.AI.MIT.EDU; Thu, 6 Jul 89 19:20:17 edt
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA21801; Thu, 6 Jul 89 13:54:17 EDT
Posted-Date: Thu, 6 Jul 89 13:54:23 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA08610; Thu, 6 Jul 89 13:54:23 EDT
Date: Thu, 6 Jul 89 13:54:23 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8907061754.AA08610@huxley.mitre.org>
To: rrrs-authors@ZURICH.ai.mit.edu
Subject: An International Character Set for R4RS
Reply-To: ramsdell@mitre.org
One way of making Scheme more inviting to Europeans, is to allow the
use of indentifiers which include letters from their alphabet. I
would like a sentences added to R4RS which encourages the support of
the ISO Latin-1 character set. Of course, no implementation would be
required to support all of the ISO Latin-1 character set.
John
∂06-Jul-89 1902 @mc.lcs.mit.edu:Pavel.pa@xerox.com Re: Assignment to standard variables
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89 19:02:19 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12449;
6 Jul 89 21:55 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Jul 89 21:52:57 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa12246; 6 Jul 89 21:42 EDT
Received: from Salvador.ms by ArpaGateway.ms ; 06 JUL 89 18:41:51 PDT
Date: Thu, 06 Jul 89 18:42:56 PDT
From: Pavel.pa@xerox.com
Subject: Re: Assignment to standard variables
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890706-184151-9881@Xerox>
I'm too tired to keep fighting about (I mean, discussing) this issue. I
withdraw the proposal.
Pavel
∂06-Jul-89 2228 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #154
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89 22:28:36 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17259;
7 Jul 89 1:12 EDT
Date: 7 JUL 89 00:09:39 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #154
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907070112.aa17259@mintaka.lcs.mit.edu>
Scheme Digest #154 7 JUL 89 00:09:39 EDT
Today's Topics:
Scheme Digest #151
Looking for MIT C-scheme manual
----------------------------------------------------------------------
Date: 3 JUL 89 00:09:16 EDT
From: Automatic Scheme Digestifier <daitc!mc.lcs.mit.edu!Scheme-Request@dsac.dla.mil>
Subject: Scheme Digest #151
Reply-To: daitc!mc.lcs.mit.edu!Scheme@dsac.dla.mil
Message-Id: <8907030101.aa21379@mintaka.lcs.mit.edu>
Scheme Digest #151 3 JUL 89 00:09:16 EDT
Today's Topics:
OOP in Scheme
----------------------------------------------------------------------
Date: 2 Jul 89 07:31:07 GMT
From: Brian of ASTD-CP <brian@jade.berkeley.edu>
Subject: OOP in Scheme
Message-Id: <1404@jato.Jpl.Nasa.Gov>
; methods2.scm
;
; ===============================================================
; Brian Beckman | brian@topaz.jpl.nasa.gov
; Mail Stop 510-202 | (818) 397-9207
; Jet Propulsion Laboratory |
; Pasadena, CA 91109 | 30 June 1989
; ===============================================================
; INTRODUCTION
;
; This is a tiny object-oriented programming system with multiple
; inheritance and error handling. It is modeled after the message
; passing modules in Chapter 3 of Abelson & Sussman. It is
; implemented in ``pure'' Scheme, without macros or syntax
; extensions.
;
; This programming system is implemented as a technique, or
; programming convention, with some helper routines. The programming
; convention is not enforced, as we choose to avoid syntax-extensions
; for portability's sake. The technique is illustrated in this file
; with a few examples. In example one, a parent class, named
; ``parent,'' passes its attributes to a child named ``child.'' In
; example two, two parents, ``mother'' ``fater'', pass their attributes
; to a child class, ``daughter.'' The reader will perceive the technique
; by generalization from these examples and will be able to apply it
; to his or her own problems.
;
; Every class is represented by its constructor procedure. This
; procedure returns a message dispatching procedure. The message
; dispatching procedure should be named ``self'' so that an object can
; conveniently send messages to itself. However, ``self'' is an
; internal name not known outside the constructor.
;
; In summary, classes are represented by constructor procedures, and
; objects, or instances of classes, are represented by message
; dispatching procedures. The present version of ``methods'' does not
; support code sharing, so every instance of a class has its own
; private copies of the method code. We expect to implement code
; sharing in a later version of ``methods''.
;
; The message dispatching procedure walks the multiple inheritance
; hierarchy upwards until it finds an object that can understand a
; message, starting with itself. If no object that can understand the
; message is found, a global error procedure is called.
;
; IMPLEMENTATION
;
; Error processing is challenging. We should like to have two modes.
; In ``normal mode'', an error is reported only by the first receiver
; of a message. In ``debug mode'', an inheritance traceback should be
; given whereby every object in an inheritance hierarchy will report
; when it fails to recognize a given message. The following variable
; represents that mode. (For simplicity, this object is hidden only
; by its name, which is unusual enough that it is unlikely to be
; trammeled by an application. This is not the recommended technique
; for data hiding. Data hiding ought to be implemented through the
; techniques shown in this file! However, since this error handling
; part of the methods package is considered system programming,
; certain liberties in style are justifiable. There are in fact, good
; technical reasons for the error handling code to be implemented with
; global variables, which the perceptive reader will be able to
; deduce.)
(define **method-mode** 'normal-method-mode)
; The user can set these modes as follows.
(define (set-debug-method-mode)
(set! **method-mode** 'debug-method-mode))
(define (set-normal-method-mode)
(set! **method-mode** 'normal-method-mode))
(define (reset-debug-method-mode) ;;; synonym
(set! **method-mode** 'normal-method-mode))
; and test them with the following routine:
(define (test-debug-method-mode)
(eq? **method-mode** 'debug-method-mode))
; Before presenting the examples of classes and objects, some helper
; routines are needed.
;
; When an object cannot recognize a message, and none of its ancestor
; objects can recognize it, the object creates an error procedure and
; returns it as the result of the message dispatcher.
(define **method-error-class-name** "No class name.")
(define **method-error-message** 'no-message)
(define (error-method . junk-args)
(display **method-error-class-name**)
(display ": uknown message: '")
(display **method-error-message**)
(newline)
())
(define (make-error-method class-name msg)
(set! **method-error-class-name** class-name)
(set! **method-error-message** msg)
error-method)
; The procedure that walks the inheritance hierarchy must cooperate
; in the error handling.
(define (search-supertypes supers msg)
(define method ())
(if (test-debug-method-mode)
(begin
(display "Searching...")
(newline)))
(cond
( (null? supers) () )
( (begin
(set! method ((car supers) msg))
(eq? method error-method))
(if (test-debug-method-mode)
(error-method))
(search-supertypes (cdr supers) msg) )
( else method )))
; This procedure implements the inheritance of methods. It is greatly
; complicated by proper error handling. Without error handling, the
; routine would resemble the following, which is much easier to
; understand (without error handling, the programming convention is
; that an object that does not understand a message returns the
; unexecutable method ``()'').
;
; (define (search-supertypes supers msg)
; (cond
; ( (null? supers) () )
; ( ((car supers) msg) )
; ( else (search-supertypes (cdr supers) msg) )))
;
; The actual routine, with proper error handling, works as follows. A
; local variable, ``method'', is defined. Its value is not important
; to begin with. If debugging is on, we print a message telling the
; user that the inheritance hierarchy is being searched. Then, the
; list of supertypes is investigated. If the list is empty, we return
; nil, which signals the caller to create and return the error-method,
; as we shall see in the examples later. If the list is not empty, we
; pass the message to the first supertype in the list. The return
; value is assigned to the local variable ``method''. If the returned
; method is the one and only global error-method, then the supertype,
; and, recursively, all its supertypes, did not know the message.
; If debugging is on, we execute the returned error-method, contributing
; to the aforementioned inheritance traceback. Finally, we return
; the value of a recursive call of search-supertypes on the remainder
; of the list of supertypes. If the returned method is not the
; error-method, then the supertype did understand the message after
; all somewhere in the hierarchy, and the returned method is the
; return value of this procedure.
;
; Note that the list of supertypes is searched in order from front
; to back. The first match of a message results in the successful
; finding of a method. The order of supertypes in the list is
; significant only when more than one supertype can understand
; a given message. The earlier members of the list will shadow
; the later ones. In some object-oriented programming systems, one
; refers to the ``overriding'' of methods. The shadowing in
; ``methods'' is our form of method overriding, and it is under
; explicit control of the programmer who sets the order of supertypes
; in the list of supertypes.
;
; In summary, search-supertypes passes the message to the ancestors,
; in pre-order, returning the first method found.
;
; The next helper routine passes a message, and a variable number of
; arguments, to all the parents of an object. For side effects, it
; executes any methods found. Parents are defined as
; first level ancestors.
(define (for-all-parents supers msg . args)
(let ( (method-list
(map (lambda (supertype) (supertype msg)) supers))
(for-proc
(lambda (method) (apply method args))) )
(for-each for-proc method-list)))
; With the current programming convention, it is not possible to pass
; a message to all ancestors and execute the methods for side-effect
; without explicit cooperation on the part of the objects involved. In
; other words, the procedure ``for-all-ancestors'', analogous to
; ``for-all-parents'', cannot be implemented in the current version of
; the methods package. The reason is that the convention calls for
; every class to call ``search-supertypes'', which stops when it finds
; a method. The convention would have to be augmented so that objects
; would call ``find-all-methods'' (defined below) on an appropriate
; message. Since we expect the need for ``for-all-ancestors'' to be
; fairly rare, the necessary changes to the methods package will be
; reserved for a future version.
(define (find-all-methods supers msg)
(cond
( (null? supers) () )
( else (cons ((car supers) msg)
(find-all-methods (cdr supers) msg)) )))
; EXAMPLES (cut here to end of file to throw examples away)
;
; Our first example class, or object type, is ``parent'', represented
; by the following constructor procedure.
(define (new-parent arg)
(let ((state-var (* arg arg))
(supers ()))
(define (report-state-var)
(display state-var)
(newline)
state-var)
(define (update-state-var arg)
(set! state-var (* arg arg)))
(define (echo arg)
(display arg) (newline))
(define (self msg)
(cond
( (eq? msg 'report) report-state-var )
( (eq? msg 'update) update-state-var )
( (eq? msg 'echo) echo )
( (search-supertypes supers msg) )
( else (make-error-method "Parent" msg) )))
self))
; This class, or constructor procedure, completely illustrates, by
; example, the programming convention of the ``methods'' technique.
; The constructor takes a single argument, whose square it stores in a
; local state variable. Another state variable, the list of
; supertypes, is set to nil, since this class is at the root of an
; inheritance hierarchy. Three methods are defined, one that reports
; and returns the current value of the state variable, one that sets
; the state variable equal to a new square, and one that merely echoes
; its argument. A method dispatching procedure, conventionally named
; ``self'', tests a given message against three symbols and returns
; the corresponding method if a match is found. If no match is found,
; the list of supertypes is searched for a match. In the case of this
; class, ``parent'', the search is purely formal, to illustrate how it
; should be done, since ``parent'' has no ancestors. However, if a
; match were found among the list of supertypes, the method would be
; returned. Note how the search relys on the fact that any non-nil
; result is treated as a successful ``cond'' clause, terminating the
; ``cond'' statement. Search-supertypes returns nil only when a match
; is not found. Finally, if no match is found locally or among the
; supertypes, an appropriate error-method is pseudo-created and
; returned.
;
; We now test this class by making an instance and passing it
; messages.
(define p (new-parent 42))
((p 'report))
((p 'update) 69)
((p 'report))
((p 'echo) (list 1 2 3))
; We test error handling:
((p 'bogus))
(set-debug-method-mode)
((p 'bogus))
(reset-debug-method-mode)
((p 'bogus) 'here 'are 'some 'junk 'arguments)
; Continuing this example, let us define a child class inheriting
; all attributes and methods of the parent. Note the attributes of
; the parent are only accessible through the parent's method
; discipline. This is a strict form of inheritance, and the default
; in C++, for example. (C++ allows the programmer to override
; ancestors' access discipline, at his own peril.)
(define (new-child arg1 arg2)
(let* ( (leg1 (* arg1 arg1))
(leg2 (* arg2 arg2))
(hypotenuse (+ leg1 leg2))
(supers (list
(new-parent hypotenuse))) )
(define (report)
(for-all-parents supers 'report)
(display "Leg1 = ") (display (sqrt leg1)) (newline)
(display "Leg2 = ") (display (sqrt leg2)) (newline)
(display "Hypo = ") (display (sqrt hypotenuse)) (newline))
(define (update-leg1 val)
(set! leg1 (* val val))
(set! hypotenuse (+ leg1 leg2)))
(define (update-leg2 val)
(set! leg2 (* val val))
(set! hypotenuse (+ leg1 leg2)))
(define (self msg)
(cond
( (eq? msg 'report) report )
( (eq? msg 'update-leg1) update-leg1 )
( (eq? msg 'update-leg2) update-leg2 )
( (search-supertypes supers msg) )
( else (make-error-method "Child" msg) )))
self))
; We now test the child type.
(define c (new-child 3 4))
((c 'report)) ;;; passes message to all parents
((c 'update-leg1) 5)
((c 'update-leg2) 12)
((c 'report))
((c 'echo) '(foo bar)) ;;; msg known only in the parent
((c 'bogus) 'baz 'rat)
(set-debug-method-mode)
((c 'bogus) 'baz 'rat)
(reset-debug-method-mode)
((c 'bogus) 'baz 'rat)
; The last example, presented without detailed narrative, shows a
; slightly deeper inheritance hierarchy. The leaf is a type named
; ``daughter''. Its two parent classes are ``mother'' and ``father''.
; In turn, every mother has an ``estate'' and a ``religion'' (please
; excuse the somewhat strained metaphor of inheritance; this is just
; a little example).
(define (new-estate value)
(let ((value value)
(supers ()))
(define (report)
(display "Estate = $") (display value) (newline))
(define (what-value) value)
(define (increase amount) (set! value (+ value amount)))
(define (decrease amount) (set! value (- value amount)))
(define (self msg)
(cond
( (eq? msg 'report) report )
( (eq? msg 'what-estate) what-value )
( (eq? msg 'increase) increase )
( (eq? msg 'decrease) decrease )
( (search-supertypes supers msg) )
( else (make-error-method "Estate" msg) )))
self))
(define (new-religion theReligion)
(let ((religion theReligion)
(supers ()))
(define (report) (display "Religion = ") (display religion) (newline))
(define (what-religion) religion)
(define (convert theNewReligion) (set! religion theNewReligion))
(define (self msg)
(cond
( (eq? msg 'report) report )
( (eq? msg 'convert) convert )
( (eq? msg 'what-religion) what-religion )
( (search-supertypes supers msg) )
( else (make-error-method "Religion" msg) )))
self))
(define (new-father eye-color)
(let ((eye-color eye-color)
(supers ()))
(define (report) (display "Father's eye color = ")
(display eye-color) (newline))
(define (what-eye-color) eye-color)
(define (self msg)
(cond
( (eq? msg 'report) report )
( (eq? msg 'what-eye-color) what-eye-color )
( (search-supertypes supers msg) )
( else (make-error-method "Father" msg) )))
self))
(define (new-mother eye-color estate religion)
(let ((eye-color eye-color)
(supers (list
(new-estate estate)
(new-religion religion))))
(define (report)
(for-all-parents supers 'report)
(display "Mother's eye color = ")
(display eye-color) (newline))
(define (what-eye-color) eye-color)
(define (self msg)
(cond
( (eq? msg 'report) report )
( (eq? msg 'what-eye-color) what-eye-color )
( (search-supertypes supers msg) )
( else (make-error-method "Mother" msg) )))
self))
(define (new-daughter eye-color)
(let* ((eye-color eye-color)
(parents-eye-color
(if (eq? eye-color 'blue) 'blue 'brown))
(supers (list
(new-father parents-eye-color)
(new-mother parents-eye-color 500000 'Jewish))))
(define (report)
(for-all-parents supers 'report)
(display "Daughter's eye color = ")
(display eye-color)
(newline))
(define (what-eye-color) eye-color)
(define (self msg)
(cond
( (eq? msg 'report) report )
( (eq? msg 'what-eye-color) what-eye-color )
( (search-supertypes supers msg) )
( else (make-error-method "Daughter" msg) )))
self))
(define dbl (new-daughter 'blue))
((dbl 'report))
((dbl 'convert) 'muslim)
((dbl 'report))
((dbl 'increase) 50000)
((dbl 'report))
(define dbr (new-daughter 'brown))
((dbr 'report))
((dbr 'decrease) 250000)
((dbr 'report))
((dbr 'bogus))
(set-debug-method-mode)
((dbr 'bogus))
(reset-debug-method-mode)
------------------------------
End of Scheme Digest
********************
------------------------------
Date: 6 Jul 89 21:33:25 GMT
From: Brian of ASTD-CP <brian@topaz.rutgers.edu>
Subject: Looking for MIT C-scheme manual
Message-Id: <1415@jato.Jpl.Nasa.Gov>
We here in the Computer Graphics Lab have MIT cscheme running
and we have the R3RS to look at. But cscheme has a tremendous
number of features, extensions, and goodies that we haven't
figured out. Is there a reference manual? A user's manual?
If someone has it, would s/he be so kind as to e-mail (or even
US snail) it to us? We're limping along with MacScheme and
various installations of Betz's Xscheme, which, while very nice
indeed, doesn't seem to have the power, backing, (nor size) of
cscheme by an order of magnitude or so.
;================================================================
;| Brian Beckman | brian@topaz.jpl.nasa.gov |
;| Computer Graphics Laboratory | (818) 397-9207 |
;| Mail Stop 510-202 | (818) 397-9344 |
;| Jet Propulsion Laboratory | |
;| Pasadena, CA 91109 | 6 July 1989 |
;================================================================
------------------------------
End of Scheme Digest
********************
∂07-Jul-89 1700 @mc.lcs.mit.edu:Pavel.pa@xerox.com Re: Reserving a character for experimentation
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 7 Jul 89 17:00:31 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa08503;
7 Jul 89 19:54 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 7 Jul 89 19:51:08 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa08273; 7 Jul 89 19:36 EDT
Received: from Salvador.ms by ArpaGateway.ms ; 07 JUL 89 16:29:22 PDT
Date: Fri, 07 Jul 89 16:31:25 PDT
From: Pavel.pa@xerox.com
Subject: Re: Reserving a character for experimentation
In-reply-to: <8907061359.AA00613@peanut.DEC.COM>
To: rrrs-authors@mc.lcs.mit.edu
Reply-To: Pavel.pa@xerox.com
Message-ID: <890707-162922-12108@Xerox>
It is indeed the case that, were we to agree to remove colon from the list
of allowed characters in identifiers, some now portable code would become
unportable. This is not a new concept. For example, we recently agreed to
de-specify the truth value of the empty list; a far, far more subtle way to
break previously portable code.
The argument must be that there is no consensus for making this particular
incompatible change to the language; that is, as a group, we must not
believe that the benefits of making colon available for experiementation
outweigh the costs of rendering some code unportable.
I do not agree with this view, obviously, but I value the consensus model
of decision. Thus, absent any signs of support other than from Alan
(thanks), I will withdraw yet another proposal. In so doing, though, I
would like to make two requests to the authors as a group:
1 -- Please don't change the language to allow ``#'' in identifiers; it has
been hard enough to find an acceptable character this once and I'd rather
not have to go through it again.
2 -- Over the past few weeks, I have watched no fewer than seven ideas
proposed to this mailing list. By my count, that number exceeds the number
of people stating opinions on those ideas. It is very difficult to attempt
to achieve a consensus among a large group if the vast majority are silent.
What are we to assume about those who say nothing? That they approve of
what is being said? By whom? That, perhaps, they care nothing about the
ideas being discussed and thus have no interest in how they are resolved?
I hope not.
In a recent message, Jinx noted the following:
``I'm afraid we are going to disagree very strongly on this issue, and
therefore we are at an impasse. Unfortunately that seems to be happening
with everything else that anyone proposes, so I'm afraid that R3.95RS is
the end of the line. What a pity.''
A pity indeed, if it means that Scheme will not evolve into a usable
standard language. If we ever hope for wider use of this language, we must
work harder to resolve differences and, critically, MOVE FORWARD. That
requires work, attention, and above all, participation.
End of sermon/supplication.
Pavel
∂07-Jul-89 1740 @mc.lcs.mit.edu,@ti.com:bartley@m2.csc.ti.com Responses to a month of mail
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 7 Jul 89 17:40:28 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09099;
7 Jul 89 20:36 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 7 Jul 89 20:33:16 EDT
Received: from TI.COM by mintaka.lcs.mit.edu id aa09044; 7 Jul 89 20:30 EDT
Received: by ti.com id AA28102; Fri, 7 Jul 89 19:30:51 CDT
Received: from m2.csc.ti.com.UUCP by tilde id AA29680; Fri, 7 Jul 89 14:45:28 CDT
Received: by m2.csc.ti.com.UUCP (5.52/4.7)
id AA11314; Fri, 7 Jul 89 14:45:25 CDT
Date: Fri, 7 Jul 89 14:45:25 CDT
From: David Bartley <bartley@m2.csc.ti.com>
Message-Id: <8907071945.AA11314@m2.csc.ti.com.UUCP>
To: JMiller%crl.dec@decwrl.dec.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: jmiller@crl.dec.com's message of Wed, 5 Jul 89 16:53:13 EDT <8907052053.AA00249@peanut.DEC.COM>
Subject: Responses to a month of mail
Reply-To: Bartley@ti-csl.csc.ti.com
>From: jmiller@crl.dec.com
>
>I'd like to suggest that Pavel use "|" instead of ":" for his module
>separator. It's currently illegal, and I believe that his argument
>against its use (other dialects use it for an escape character) is
>very weak. It also looks pretty good for just this purpose:
>
>(module|submodule|procedure random-thing)
>
>--Jim
At least four of our implementations of Scheme use "|" the same way
Common Lisp uses it: to make funny characters seem alphabetic in
symbol names. I would also expect this to be true of other Scheme's
out there that are piggy-backed on top of other Lisps. This could
work against Pavel's module mechanism spreading to those systems.
On the other hand, I kind of like the looks of your example. Suppose
we used paired "||" instead? It seems to me that there would be no
conflict between the two uses of "|" (except perhaps readability).
(module||submodule||procedure random-thing)
--db--
∂08-Jul-89 1717 @mc.lcs.mit.edu,@sonoma.stanford.edu:shap@annabel.stanford.edu Fluid binding
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 8 Jul 89 17:17:28 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03309;
8 Jul 89 20:12 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Jul 89 19:11:24 EDT
Received: from sonoma.Stanford.EDU by mintaka.lcs.mit.edu id aa02588;
8 Jul 89 19:09 EDT
Received: by sonoma.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00432; Sat, 8 Jul 89 16:09:33 PDT
Message-Id: <8907082309.AA00432@sonoma.Stanford.EDU>
Received: from annabel.STANFORD.EDU by dolores; Sat, 8 Jul 89 16:10:19 pdt
Received: by sid; Sat, 8 Jul 89 14:03:02 pdt
Date: Sat, 8 Jul 89 14:03:02 pdt
From: "Jonathan S. Shapiro" <shap@annabel.stanford.edu>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Wed, 05 Jul 89 21:05:31 PDT <890705-210534-7725@Xerox>
Subject: Fluid binding
Several comments:
This is syntactically gross. The presence of FLUID-REF in effect
separates things into two namespaces, which is awful. I also don't
like the fact that FLUID-LET evaluates its variables.
People may not like it, but I think this wouldbe better handled as
follows:
(DEFINE FRED)
(DECLARE FRED 'fluid)
LET continues to work as you expect, but when applied to a fluid
variable does a fluid-let. Within the context of such a fluid-let, as
set! behaves in the way one expects.
I fail to see why we need any additional syntax to accomplish this.
Perhaps someone can enlighten me.
∂08-Jul-89 1732 @mc.lcs.mit.edu,@sonoma.stanford.edu:shap@annabel.stanford.edu Assignment to standard variables
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 8 Jul 89 17:32:14 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03421;
8 Jul 89 20:20 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Jul 89 19:11:32 EDT
Received: from sonoma.Stanford.EDU by mintaka.lcs.mit.edu id aa02590;
8 Jul 89 19:09 EDT
Received: by sonoma.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00436; Sat, 8 Jul 89 16:09:35 PDT
Message-Id: <8907082309.AA00436@sonoma.Stanford.EDU>
Received: from annabel.STANFORD.EDU by dolores; Sat, 8 Jul 89 16:10:23 pdt
Received: by sid; Sat, 8 Jul 89 13:56:43 pdt
Date: Sat, 8 Jul 89 13:56:43 pdt
From: "Jonathan S. Shapiro" <shap@annabel.stanford.edu>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Wed, 05 Jul 89 20:04:36 PDT <890705-200443-7674@Xerox>
Subject: Assignment to standard variables
I think pavel has missed several points.
Regarding being unable to rebind `if', `or', `delay', etc. There is a
distinction to be made between symbols that are syntax and symbols
that are functions. One of the beauties of scheme is that the set of
identifiers that is reserved is very small. It is also unlikely to
change very much. This makes the syntactic keywords rather different
from the standard functions that are part of the environment. There
is less risk of incompatible extension, and there are strong
experiential arguments (e.g. Algol) for not having syntactic keywords
be assignable. Indeed, making things like IF assignable would
introduce a fundamental ambiguity into the language.
Lexical scoping is insufficient to get around this problem, partly
because of the define semantics issue. It is not the case that I can
take a randomchunk of code and stick it inside a LETREC somewhere and
have things remain consistent. In particular, the following two code
fragments are not identical. One is an error:
(DEFINE foo 3) (let ()
(SET! foo 4) (DEFINE foo 3)
(DEFINE bar 5) (SET! foo 4)
(DEFINE bar 5))
What is needed here is environments, and the only thing that we all
seem to be able to agree on with regard to environments is that we
disagree strongly on what they should be like.
The requirement of a clean syntactic mode doesn't get you out of the
incompatibility problem, unless I have misunderstood the intent of
R3.95RS in this regard. The clean environment prohibits extensions to
the standard-described language, yes. It doesn't, however, prohibit
changes to the standad. In R5RS the standard might change in a way
that breaks existing programs if we adopt your proposal. This should
be avoided if possible.
I also believe that your interpretation of "it is an error" is wrong.
When we state that behavior is unspecified, we mean that it is is
unspecified. When we state that something is an error, we mean that
it is a wrong thing to do, not that it is unspecified. The fact that
implementations are permitted to be lazy is not a good rationale for
destroying the meaning of "it is an error."
Frankly, I think that the idea of creating a DECLARE form makes the
most sense of all. It would let the decision of immutability be left
with the programmer without compromising any of Pavel's objectives.
In one regard, however, I agree with Pavel. The transformation that
was proposed for environments is sufficiently verbose that it is a
pain in the ass to use, and I agree with him that it is undesirable.
I also agree that the right character to use, if any, is `:', for the
reasons he stated.
Jon
∂08-Jul-89 1751 @mc.lcs.mit.edu,@sonoma.stanford.edu:shap@annabel.stanford.edu Reserving a character for experimentation
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 8 Jul 89 17:51:16 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03548;
8 Jul 89 20:30 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Jul 89 19:22:31 EDT
Received: from sonoma.Stanford.EDU by mintaka.lcs.mit.edu id aa02611;
8 Jul 89 19:11 EDT
Received: by sonoma.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00428; Sat, 8 Jul 89 16:09:28 PDT
Message-Id: <8907082309.AA00428@sonoma.Stanford.EDU>
Received: from annabel.STANFORD.EDU by dolores; Sat, 8 Jul 89 16:10:16 pdt
Received: by sid; Sat, 8 Jul 89 14:07:15 pdt
Date: Sat, 8 Jul 89 14:07:15 pdt
From: "Jonathan S. Shapiro" <shap@annabel.stanford.edu>
To: JMiller@crl.enet.dec.com
Cc: Pavel.pa@xerox.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: jmiller@crl.dec.com's message of Thu, 6 Jul 89 09:59:48 EDT <8907061359.AA00613@peanut.DEC.COM>
Subject: Reserving a character for experimentation
> Perhaps what you meant is that no individual's code running
> in an existing implementation would be affected -- but I'm more
> worried about the portable code I've written over the years. I'd like
> it to remain portable, and your suggesting one more headache to worry
> about.
I don't find this argument particularly compelling, given that the
program to transform colon-using code to non-colon-using-code is so
short.
Jon
∂08-Jul-89 2224 @mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu Fluid binding
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 8 Jul 89 22:24:08 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06119;
9 Jul 89 1:03 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 9 Jul 89 00:55:14 EDT
Received: from [18.43.0.171] by mintaka.lcs.mit.edu id aa05972;
9 Jul 89 0:53 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Sun, 9 Jul 89 00:50:33 edt
Date: Sun, 9 Jul 89 00:50:33 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8907090450.AA01092@ZURICH.AI.MIT.EDU>
To: shap@annabel.stanford.edu
Cc: Pavel.pa@xerox.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: "Jonathan S. Shapiro"'s message of Sat, 8 Jul 89 14:03:02 pdt <8907082309.AA00432@sonoma.Stanford.EDU>
Subject: Fluid binding
This is syntactically gross. The presence of FLUID-REF in effect
separates things into two namespaces, which is awful. I also don't
like the fact that FLUID-LET evaluates its variables.
The only syntax in Pavel's proposal is FLUID-LET, the others are
procedures. His proposal does not introduce another namespace.
Instead of adding a new kind of environment or variable, he makes
fluids first class objects whose contents are context sensitive.
The name fluid is loaded, think of them as cells (pairs with only one
component).
People may not like it, but I think this wouldbe better handled as
follows:
(DEFINE FRED)
(DECLARE FRED 'fluid)
LET continues to work as you expect, but when applied to a fluid
variable does a fluid-let. Within the context of such a fluid-let, as
set! behaves in the way one expects.
This is virtually impossible to implement correctly in the presence of
separate compilation. The only way to get this to work would be to
make the assumption that all free variables are special (I mean fluid,
sorry), which is what Common Lisp does.
I fail to see why we need any additional syntax to accomplish this.
Perhaps someone can enlighten me.
Pavel's proposal does not require syntax, since FLUID-LET can be
replaced by a procedure as I suggested in a previous message. On the
other hand, FLUID-LET would be the most common way of using fluids,
and the procedures would hardly ever be used directly.
∂09-Jul-89 2121 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #155
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 9 Jul 89 21:21:42 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01550;
10 Jul 89 0:19 EDT
Date: 10 JUL 89 00:09:37 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #155
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907100019.aa01550@mintaka.lcs.mit.edu>
Scheme Digest #155 10 JUL 89 00:09:37 EDT
Today's Topics:
Learning/teaching Scheme as a first language - Summary
----------------------------------------------------------------------
Date: 7 Jul 89 15:59:06 GMT
From: Dave McKellar <mailrus!jarvis.csri.toronto.edu!utgpu!utzoo!yunexus!intacc!mckellar@ohio-state.arpa>
Subject: Learning/teaching Scheme as a first language - Summary
Message-Id: <1989Jul7.115906.7544@intacc.uucp>
Many thanks to the 16 kind people who replied to my query about
an easy reading book on Scheme. Here is what they said...
Easy Reading Books on Scheme
============================
The Little Lisper by Daniel P. Friedman and Matthias Felleisan
----------------- of Indiana University
Programming in Scheme by Mike Eisenberg
--------------------- published by Scientific Press
The Scheme Programming Language by Kent Dybvig
------------------------------- published by Prentice Hall
Introduction to Scheme by Jerry Smith
---------------------- published by Prentice Hall
The 'World's biggest bookstore', here in Toronto, has a shelf of Lisp
books but none of these.... shocking!
--
----------
{uunet,watmath,utzoo}!mnetor!intacc!mckellar "Taste is a matter of taste."
----------
------------------------------
End of Scheme Digest
********************
∂10-Jul-89 1447 @MC.lcs.mit.edu:Alan@REAGAN.ai.mit.edu R↑3.95RS: open-input-file open-output-file
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 10 Jul 89 14:47:48 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25367;
10 Jul 89 17:13 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 10 Jul 89 17:10:36 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 233698; Mon 10-Jul-89 17:09:51 EDT
Date: Mon, 10 Jul 89 17:09 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Subject: R↑3.95RS: open-input-file open-output-file
To: JMiller@crl.enet.dec.com, rrrs-authors@MC.lcs.mit.edu
In-Reply-To: <8907052107.AA00259@peanut.DEC.COM>
Message-ID: <19890710210947.5.ALAN@PIGPEN.AI.MIT.EDU>
Date: Wed, 5 Jul 89 17:07:22 EDT
From: jmiller@crl.dec.com
At the risk of opening an entire can of worms, what about passing an
optional flag in to OPEN-... specifying (if present and EQ? to #T)
that a return value of #F is valid....
The Lisp Machine system's OPEN used to do something like this. If you gave
it the right flag as an optional argument, OPEN would either return a open
stream, or an "error object" that described why the file couldn't be
opened. This style of programming turned out to be very clumsy and error
prone. Once you start returning streams and error objects from the same
function, the next step is to store them both in the same variables. Then
you've got them in the same slots in data structures. Passing an error
object to an I/O primitive as a stream becomes a common path into the
debugger. Also other functions that return streams might want to return
error objects as well, so then they need to support the same optional flag
argument.
The condition system that replaced this style of OPEN was an immeasurable
improvement.
∂10-Jul-89 2055 @mc.lcs.mit.edu,@decwrl.dec.com:jmiller@crl.dec.com LIST-REF, revisited
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 10 Jul 89 20:55:50 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28793;
10 Jul 89 20:09 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 10 Jul 89 16:35:22 EDT
Received: from decwrl.dec.com by mintaka.lcs.mit.edu id aa23490;
10 Jul 89 16:30 EDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
id AA02002; Mon, 10 Jul 89 13:29:53 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
for rrrs-authors@mc.lcs.mit.edu; id AA02002; Mon, 10 Jul 89 13:29:53 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
id AA12173; Mon, 10 Jul 89 13:44:02 EDT
Date: Mon, 10 Jul 89 13:40:41 EDT
From: jmiller@crl.dec.com
Message-Id: <8907101740.AA02171@peanut.DEC.COM>
To: rrrs-authors@mc.lcs.mit.edu
Subject: LIST-REF, revisited
Reply-To: JMiller@crl.enet.dec.com
At the recent IEEE Working Group meeting it was proposed that we again
respectfully request the Authors to consider the inclusion of the
procedure LIST-REF. The argument is fundamentally to provide parallel
constructs for strings, lists, and vectors. The Authors have already
adopted the addition of STRING to aid in this effort. It was the
consensus of the meeting that the omission of LIST-REF from the IEEE
Draft Standard was undesirable, while the omission of LIST-TAIL was
acceptable since no similar procedure exists for the other data types.
Can we reach consensus on this one procedure?
--Jim Miller
P.S. -- I (personally, as opposed to the IEEE WG meeting) urge the
Authors to carefully re-read Morry Katz's initial proposal for
regularizing the data types. Perhaps Morry can find a copy of his
earlier message, reconsider it, and resubmit it for comments. I don't
believe that it can be acted on in time for the IEEE Draft, but
certainly R5RS is an appropriate vehicle for these considerations.
∂11-Jul-89 0857 @mc.lcs.mit.edu,@ZURICH.ai.mit.edu:ramsdell@linus.mitre.org International character sets.
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 11 Jul 89 08:57:11 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07559;
11 Jul 89 9:33 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Jul 89 09:28:39 EDT
Received: from ZURICH.AI.MIT.EDU by mintaka.lcs.mit.edu id aa07464;
11 Jul 89 9:23 EDT
Received: from mbunix.mitre.org ([129.83.20.100]) by ZURICH.AI.MIT.EDU; Tue, 11 Jul 89 09:20:24 edt
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA07932; Tue, 11 Jul 89 09:19:43 EDT
Posted-Date: Tue, 11 Jul 89 09:19:37 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA00208; Tue, 11 Jul 89 09:19:37 EDT
Date: Tue, 11 Jul 89 09:19:37 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8907111319.AA00208@huxley.mitre.org>
To: rrrs-authors@ZURICH.ai.mit.edu
Subject: International character sets.
Reply-To: ramsdell@mitre.org
Here is a more specific proposal on international character sets.
Add the following sentence to the begining of paragraph -2, column 2,
page 4, which descibes when upper and lower case letters are
destinguished.
Implementations are encouraged to support at least
the ISO Latin 1 (ISO8859-1) character set.
John
PS. On the internationalization of Eiffel
From: sommar@enea.se (Erland Sommarskog)
Newsgroups: comp.lang.eiffel
Date: 8 Jul 89 20:40:27 GMT
Organization: Enea Data AB, Sweden
In one of his many interesting articles Bertrand Meyer said if one
wants changes in Eiffel the next six months is the time to ask for
them. Since I think Eiffel has to be improved with regards to supporting
human langauges other English, I will try to summarize the potential
problem areas I'm aware of. I'm not an expert in neither Eiffel nor
character-set standards, so I will not try to provide complete solutions,
but merely point out the requirements.
Before I go any further, let me add that these problems are in no
way unique to Eiffel. Since some time ISO requires support of multi-
national character sets when they are approving or revising a
language standard. The problems connected with this vary from langauge
to langauge, as do the solutions.
I first give an overview of existing character sets. I then discuss
the various problem areas: Operator and delimiter characters, literals,
identifiers and finally operations as comparisons.
!
Standardized character sets
---------------------------
There are several character-set standards, which I briefly describe
since not everyone may be well acquinted with them.
ASCII - The standard on which about everything else is based.
EBCDIC - Appears in some worlds, but none I have experience of.
ISO 646 - A seven-bit standard, where some characters in the ASCII
are replaced by national characters. Which are the replace-
ments depends on the country you're in. For instance in
Sweden left brace is replaced with dotted "a", in France
it's an "e" with accent aigue.
ISO 2022 - A standard that describe how to change between different
character sets.
ISO 6937 - A eight-bit set, which doesn't seem to have been adopted
very much. Slots 0-127 are ASCII. From 161 and up are mute
modifiers and national letters. With 6937 dotted "a" is
produced by first given a diaresis and then the "a".
Virtually all langauges with a Latin alphabet, except
Vietnamese, could be written with this set.
ISO 8859 - Nine standards which all have ASCII in 0-127 and control
characters in 128-159. Then the contents varies depends on
the geographical are addressed. Five of the sets has Latin
characters, then there's one each for Cyrillic, Hebrew, Arabic
and Greek. I don't know whether all nine has finally been
settled. Some may still be drafts.
One could expect that the absolutely most commonly supported
will be 8859/1, also known as Latin-1. Latin-1 covers most
of the languages in Western Europe. (Exlcuded are Welsh and
Catalan.)
8859 has no mute characters.
ISO 10646 - A multi-octet character set, which is under development.
I know very little of it, but I doubt there is even a
draft of it. There was a posting about it in comp.std.internat
some time ago.
In the following I will conentrate on ISO 646 and 8859. Although I
personally am appealed by the ideas in 6937, its use in real life
is small, so I'm disregarding the problems that supporting this standard
would cause.
!
Operator and delimiter characters
---------------------------------
With an eight-bit set based on ASCII there are rarely any problem.
However, in a seven-bit world there are. Any programming language using
any of the characters @[\]↑`{|}~ as an operator or a delimiter is
committing a crime in my eyes. Most of the national sets that ISO 646
defines replaces these characters with national characters, and in many
cases these characters are letters. So in my eyes a notation like
class BIN_TREE [T]
is just as bad as:
class BIN_TREE ZTQ
(Read Z and Q as opening and closing delimiters!)
Many languages that use these characters alleviates the problem
by providing alternative tokens. For instance, Ada allows you use "!"
for "|". Many Pascal compilers allow "(." and ".)" for [], and (* and
*) are more common than {}.
Eiffel is a sinner in this field. With Dr. Meyer's origin in mind,
I assume he is not unaware of the problems, but has chosen to ignore
them. Still I hope he will re-think and change his mind on this issue.
Letters as special characters is simply not a good idea.
One could argue that since we're moving into a eight-bit world,
this is a disappearing problem, but remember that that transition
is slow. We will live with seven-bits terminals and printers quite
a long time still.
Now, what actual problems do we have in Eiffel? The occurance of brackets
and braces in Eiffel is restricted to the class declaration and the export
clause which gives less pain than if they could occur anywhere. Anyway,
finding replacement characters should be easy. (To be honest I don't
really see why they had been chosen in the first place. Is there some
lexical problem that prevents simple parenthesis?)
Worse is the backslash. Could you think of having to double all "W"s
in your string literals? Probably not, so you wouldn't pick "W" as
the escape character. Eiffel has chosen the bad habit from C of using
dotted "O" (which is how the backslash appears on my screen). Here
I not only want an alternate character, but also I want to get rid
of the original. (As a whole, I am not fond of the C style of writing
character and string literals, why use octal codes?)
!
Literals
--------
Which characters can I use in string and character literals? If
we forget the fatal backslash, Eiffel doesn't give me any problem
if I'm using any of the 8859 standards. It is just to go ahead and
use them. (At least that is what its description alludes. For what
happens in real life, see an adjacent article of mine.)
Other people will get problems, though, mainly Japanse and Chinese
programmers. I.e., there is no support for multi-byte sets.
As a side note, a language which really is evil here is Ada. Ada
explictly forbids non-printing charcaters in literals, and "non-
printing" is defined from ASCII, so using the upper half of Latin-1
in Ada is a real pain. Ada-9X will resolve this, but that's another
three or four years from now. Sigh.
!
Identifiers
-----------
Eiffel, as most other langauges, allows the letters in the English
alphabet in identifiers. However, if you're writing code in your native
langauge, you may need to use other letters as well. To be able to
use the replacement characters in ISO 646 would be nice, but it would
be pointless to require that.
But with eight-bit sets in 8859, it is a fair requirement that all
letters in these sets also are permitted in identifier names.
The problem lies in the difference between the sets. In Latin-1
161-191 are punctuation characters which you normally wouldn't think of
in identifier names. 192-255 are letters, with 32 as difference between
lower and upper case. (A few exceptions which I disregard here for
brevity.)
In the other Latin sets, some characters in the range 161-191 are
also letters, with 16 as the case difference.
How the non-Latin sets look like I don't know.
One could make this a very simple issue and just take Latin-1, with
the motivation that is what will be used in the known world of computing.
However, I think this would be fatal mistake. Should our friends in
Hungary, Russia and Greece be handicapped in the selection of
identifier characters? Do we know that "the known world of computing"
will forever restrict itself to to places were Western European
langauges are spoken?
Now then, how to support mulitple sets? An idea would be to have a
directive that said which character set the source code was written with.
We must of course immediately discard the idea, since this is impossible
in a modular langauge like Eiffel. (What if we want to inherit that
Latin-2 class in our Latin-1 class?)
As far as I can see the only way to go is to allow all characters
>= 161 and then use the 32 and 16 differences for case folding. (A
case significant language like C or Modula-2 has some advantage here.)
!
Operations
----------
When comparing two strings the collating sequence often has little
relevance with the alphabet. The only languages I know it works for
using ISO 646 are English, Danish, Norwegian and maybe Dutch. As a
whole one should remember that the character type in this sense is
not a simple enumerate. In many languages you only take regard to
accents and umlauts when no other character is different. And some
langauges have pairs of letters that sorts as one. (E.g. "ch" in
Spanish, "rz" in Polish.)
What you need is a set of extended comparison routines, a set of
predefined langauges and a set of routines for loading your very
own sorting order. Eiffel is extremely well prepared in this area,
particulary with the additions of infix operators in 2.2. So all
that is needed is some additions to the class library. Of course
I could write them myself, but I think they should be in the
standard library, since this is the way strings should be compared.
Using the collating sequence is a very artificial way to do it.
Or, is library additions really all we need? If we define a class
TRANSCRIPTED_STRING which codes a string to some internal format
for comparisons we would like to write:
t_str : TRANSCRIPTED_STRING;
...
t_str := "Some string";
But even if our new class is an heir of STRING, the assignment is
not permitted. And defining a TRANSCRIPTED_CHARACTER for single
elements as an heir to CHARACTER is out the question, since the
latter class is an expanded one and may not be inherited from.
One solution to these problems would of course be to inlcude
the required operations within STRING and CHARACTER. There are
probably some performance penalty for Americans who don't want
more than simple ASCII comparison, but it's certainly a solution
that looks very appealing.
It should be added here, that there are various operating systems,
not the least in the Unix sphere, that supports handling of more
than one human language which includes run-time support for
comparisons. But they are often intended for C and Eiffel gives
room for much cleaner interfaces.
In this article I have discussed very little of multi-byte characters,
since I have no experience of using them. However, they should not be
forgotten when addressing these problems. They write programs in Japan
too.
--
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
Bowlers on strike!
∂11-Jul-89 0951 @mc.lcs.mit.edu,@ZURICH.ai.mit.edu:mkatz@sesame.stanford.edu Regularization of list, vector, and string procedures
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 11 Jul 89 09:51:34 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11726;
11 Jul 89 12:34 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Jul 89 12:21:14 EDT
Received: from ZURICH.AI.MIT.EDU by mintaka.lcs.mit.edu id aa11475;
11 Jul 89 12:16 EDT
Return-Path: <mkatz@sesame.Stanford.EDU>
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by ZURICH.AI.MIT.EDU; Tue, 11 Jul 89 12:12:17 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA17846; Tue, 11 Jul 89 09:14:32 PDT
Date: Tue, 11 Jul 89 09:14:32 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907111614.AA17846@sesame.Stanford.EDU>
To: rrrs-authors@ZURICH.ai.mit.edu
Subject: Regularization of list, vector, and string procedures
At Jim Miller's request I am reposting a slightly cleaned up version of my
original proposal for regularization of the list, vector, and string procedures
in Scheme.
-------------------------------------------------------------------------------
For those of you who don't remember, I was assigned the task at L&FP to
regularize the procedures involving lists, strings, and vectors for R4RS.
Initially, this looked like a trivial, noncontroversial task; but, it turns out
that there are actually some important semantic issues to be discussed. I have
therefore decided to pass my ideas before the entire community, rather than
just sending them straight to the editors.
I will begin this discussion with what I believe are the noncontroversial
changes and then proceed to the Controversial ones. In order to better
understand the issues I have included the chart below which enumerates the
relevant procedures currently in R3RS.
LIST STRING VECTOR
---- ------ ------
list vector
make-string make-vector
string-fill vector-fill
list-ref string-ref vector-ref
string-set! vector-set!
string-copy
length string-length vector-length
append string-append
append!
list->string string->list vector->list
list->vector
reverse
substring
string=?
string? vector?
apply
map, foreach
memq, memv, member
assq, assv, assoc
Noncontroversial:
1) Add string, make-list, list-fill, list-set!, list-copy, vector-copy,
vector-append, string->vector, and vector->string with the obvious
semantics.
2) Create aliases list-length and list-append for length and append,
respectively.
3) Append! should NOT be generalized since most implementations (for good
reasons) represent strings and vectors in a manner that is incompatible
with append! semantics.
4) Reverse should NOT be generalized since the extensions would be pretty much
useless.
5) Sublist and subvector should be added because they are potentially useful
and the implementations in scheme are much less efficient than ones which
could be supplied by an implementor.
6) String=? is only present for symetry with string-ci=? and should NOT be
generalized to list=? and vector=? since we already have =?.
Controversial:
1) Create list? which checks for a null terminated list. This CAN be written
by a user and is only marginally useful, but I believe it is important that
it exist for symetry reasons.
2) Generalize apply:
(apply proc args)
(apply proc arg1 arg2 ... args)
ARGS could be any of a list, string, or vector whose elements would be
spread before the actual application was performed.
3) There are several possibilities for map and foreach:
a) Status quo
b) Introduce list-map, string-map, vector-map, list-foreach,
string-foreach, and vector-foreach. List-map and list-foreach would be
identical to the current map and foreach, respectively. The others
would have the following syntaxes and semantics
(string-map proc string1 string2 ...)
(vector-map proc vector1 vector2 ...)
(string-foreach proc string1 string2 ...)
(vector-foreach proc vector1 vector2 ...)
The string version would take strings as arguments and in the case of
string-map would return a string. The vector versions would do
similarly. It would be a type error to pass a string to list-map, a
list to vector-map, etc.
c) The same 6 procedures would be introduced as in b). In this case the
name would specify the type of the return value. The procedures would
be polymorphic over arguments of type list, string, and vector. All
that would be required would be that the arguments all have the same
length.
I am personally in favor of either b) or c). I like the semantics of c),
but realize that some members of the community may find this semantics
objectionable.
4) Memq, memv, and member are quite problematic. They could be extended to
allow the second argument to be a vector in the obvious way, but then what
should they return on a match. Returning a subvector is unsatisfactory
because the aliasing one gets with a sublist would undoubtedly not be
present for a subvector, and thus the original structure could not be
modified based on the result. In my experience, this is one of the most
common uses for these procedures and it would be negated. Another
alternative is just to return #t and #f. However, this seems to be
unintuitively incompatible with the original versions. Extensions for
strings are even worse, because the equivalence distinctions between eq,
eqv, and equal are not present and have instead been replaced by case
sensativity and insensitivity. MY RECOMMENDATION IS TO MAKE NO EXTENSION.
5) Any extensions to assq, assv, and assoc have similar problems to those of
memq, etc. and I therefore again RECOMMEND NO EXTENSION.
6) As a result of 5) and 6), I suggest adding two new families of procedures
which for the sake of exposition I will call member? and match. (I know
these are horrible names, but if people like the idea, we'll worry about
what to call them later.) Their syntaxes would be as follows:
(list-member? val pred list)
(string-member? val pred string)
(vector-member? val pred vector)
(list-match val pred list)
(string-match val pred string)
(vector-match val pred string)
The member procedures would return #f if (pred val (foo-ref foo i))
returned #f for all i, where foo is either list, string, or vector.
Otherwise, they would return #t. The match procedures would perform
similarly except that they would return the first element for which pred
returned #t, #f otherwise. A decision would have to be made for match as
to whether each element of a vector would have to itself be a vector.
Obviously, for strings each element would have to be a character and so
this version would be somewhat useless. As A RESULT, I propose that
instead we introduce just the procedures member? and match which are
polymorphic over all the reasonable types (i.e., strings, vectors, and
lists). For match, this polymorphism would extend 2 levels into the
data structure.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂11-Jul-89 1100 @MC.lcs.mit.edu,@mojave.stanford.edu:shap@sid.stanford.edu Fluid binding
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 11 Jul 89 11:00:01 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12852;
11 Jul 89 13:42 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Jul 89 13:36:59 EDT
Received: from Mojave.Stanford.EDU by mintaka.lcs.mit.edu id aa12788;
11 Jul 89 13:32 EDT
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
id AA04778; Tue, 11 Jul 89 10:29:52 PDT
Message-Id: <8907111729.AA04778@mojave.Stanford.EDU>
Received: by sid; Tue, 11 Jul 89 10:32:27 pdt
Date: Tue, 11 Jul 89 10:32:27 pdt
From: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
To: jinx@ZURICH.ai.mit.edu
Cc: Pavel.pa@xerox.com, rrrs-authors@MC.lcs.mit.edu
In-Reply-To: "Guillermo J. Rozas"'s message of Sun, 9 Jul 89 00:50:33 edt <8907090450.AA01092@ZURICH.AI.MIT.EDU>
Subject: Fluid binding
Points well taken. Thanks jinx.
My qualm about the proposal sent out boils down to the fact that it
seems like it would be cumbersome to use, but since I don't have a
better idea, I withdraw my objections.
Jon
∂11-Jul-89 1105 @MC.lcs.mit.edu,@ZURICH.ai.mit.edu:shap@sid.stanford.edu International character sets.
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 11 Jul 89 11:05:39 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12943;
11 Jul 89 13:49 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Jul 89 13:24:27 EDT
Received: from ZURICH.AI.MIT.EDU by mintaka.lcs.mit.edu id aa12619;
11 Jul 89 13:21 EDT
Return-Path: <shap@sid.STANFORD.EDU>
Received: from mojave.Stanford.EDU (mojave.stanford.edu) by ZURICH.AI.MIT.EDU; Tue, 11 Jul 89 13:18:36 edt
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
id AA04739; Tue, 11 Jul 89 10:18:38 PDT
Message-Id: <8907111718.AA04739@mojave.Stanford.EDU>
Received: by sid; Tue, 11 Jul 89 10:21:13 pdt
Date: Tue, 11 Jul 89 10:21:13 pdt
From: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
To: rrrs-authors@ZURICH.ai.mit.edu
Subject: International character sets.
If anyone thinks it would help the discussion, I would be more than
happy to send out a description of the solution that was adopted for
ANSI-C, and put forth a proposal whose purpose is only to act as a
basis for discussion describing how we might adapt it to Scheme.
Jon
∂11-Jul-89 1136 @mc.lcs.mit.edu,@ZURICH.ai.mit.edu:jar@annabel.stanford.edu Regularization of list, vector, and string procedures
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 11 Jul 89 11:36:46 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13758;
11 Jul 89 14:24 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Jul 89 14:21:04 EDT
Received: from ZURICH.AI.MIT.EDU by mintaka.lcs.mit.edu id aa13695;
11 Jul 89 14:15 EDT
Return-Path: <jar@annabel.stanford.edu>
Received: from sonoma.Stanford.EDU ([36.22.0.158]) by ZURICH.AI.MIT.EDU; Tue, 11 Jul 89 14:12:48 edt
Received: by sonoma.Stanford.EDU (5.57/Ultrix2.4-C)
id AA02184; Tue, 11 Jul 89 10:13:37 PDT
Message-Id: <8907111713.AA02184@sonoma.Stanford.EDU>
Received: from annabel.STANFORD.EDU by dolores; Tue, 11 Jul 89 10:14:22 pdt
Received: by annabel; Tue, 11 Jul 89 10:12:25 pdt
Date: Tue, 11 Jul 89 10:12:25 pdt
To: mkatz@sesame.stanford.edu
Cc: rrrs-authors@ZURICH.ai.mit.edu
In-Reply-To: Morris Katz's message of Tue, 11 Jul 89 09:14:32 PDT <8907111614.AA17846@sesame.Stanford.EDU>
Subject: Regularization of list, vector, and string procedures
From: Jonathan Rees <jar%sid.stanford.edu@polya.stanford.edu>
Sender: jar@annabel.stanford.edu
(It looks like you might not have the final version of the Revised↑3
Report. append! and =? were both flushed at the last minute. The
version that was given out at the '86 LFP conference was unfortunately
not the final version, so anyone who has one should discard it.)
I have no real problem with the "noncontroversial" changes you
enumerate, although I can't imagine any use for string->vector or
vector->string.
Generalizing apply to be generic over the type of the last argument
would constitute a strong precendent for the introduction of other
generic sequence functions, a la Common Lisp. I would prefer not to
see that happen, thus I'd rather that apply be left alone. Similarly,
I'd rather not see generic member or match.
I would rather not see any extensions to the map/for-each line that
don't do the real job, which is to improve the ways in which we can
write iterations.
∂11-Jul-89 2148 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #156
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 11 Jul 89 21:48:05 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01797;
12 Jul 89 0:38 EDT
Date: 12 JUL 89 00:10:54 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #156
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907120038.aa01797@mintaka.lcs.mit.edu>
Scheme Digest #156 12 JUL 89 00:10:54 EDT
Today's Topics:
Scheme Digest #147
----------------------------------------------------------------------
Date: Tue, 11 Jul 89 10:21:15 EST
From: "John T. Nelson" <jtn@potomac.ads.com>
Message-Id: <8907111521.AA25882@potomac.ads.com>
Subject: Re: Scheme Digest #147
If you have a pointer to the FTP'able Scheme report and/or public
domain Scheme I'd appreciate hearing about it.
------------------------------
End of Scheme Digest
********************
∂12-Jul-89 1325 @mc.lcs.mit.edu:Pavel.pa@xerox.com Fluid binding
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 12 Jul 89 13:25:09 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21337;
12 Jul 89 16:19 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jul 89 16:16:00 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa21211; 12 Jul 89 16:12 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JUL 89 11:00:17 PDT
Date: Wed, 12 Jul 89 11:00:52 PDT
From: Pavel.pa@xerox.com
Subject: Fluid binding
In-reply-to: <8907061641.AA25714@sesame.Stanford.EDU>
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890712-110017-1659@Xerox>
Morry asks for a better argument as to why shallow binding cannot be used
on shared-memory multiprocessors. It seems fairly clear to me. Consider
two threads, running on separate processors, both within the scope of a
particular lexical variable, X. When either thread assigns to X, obviously
the other thread should get the new value when it reads X. When one thread
fluid-binds X, though, it has, in effect, a new variable with the same name
over some dynamic extent; changes to the new variable should NOT be visible
to the other thread. In shallow binding, however, the new variable uses
the same storage as the old one and its ``temporary assignment'' cannot be
distinguished from any other assignment. Thus, the new value WILL be
visible to the other thread, in contradiction to the desired behavior. I
thus conclude that shallow binding is not a viable approach for fluid
variables on a shared-memory multiprocessor.
Jinx had some interesting comments:
1) MAKE-FLUID, FLUID-REF and FLUID-SET! don't have much to do with
fluids, they have to do with cells (or boxes, as some other people
call them). As such, I would like them to be renamed to
MAKE-CELL, CELL-REF, and CELL-SET!.
Alternatively we could have both MAKE-CELL, CELL-REF, CELL-SET! to
manipulate cells (the selector and mutator always provide the global
value), and FLUID-CELL-REF, FLUID-CELL-SET! to access the current
dynamic value. Which of the accessors is written on top of which
depends on whether the implementation is deep or shallow.
When I first read this, it seemed very reasonable. On later thought,
however, I concluded otherwise. For the first paragraph, I think that,
conceptually, MAKE-FLUID, FLUID-REF and FLUID-SET! have nothing to do with
cells at all. Rather, they traffic in ``fluid variables'', opaque values
that are the domain of the ``fluid environment'' (the range is locations,
just as in the lexical environment). Certainly one implementation of these
procedures (and the one I would use) has MAKE-FLUID return a cell, as you
suggest, but I think renaming them in terms of cells is a convolution of
their abstract semantics with one particular concrete realization.
I have additional problems with idea in the second paragraph. In a
shallow-binding implementation, CELL-REF is identical to FLUID-CELL-REF
while in a deep-binding implementation, their semantics is quite different.
I think it unwise for the language semantics to change depending upon a
property of the implementation that should be completely invisible.
I think that, if we want to add cells as a standard data type in the
language, we should do so separately.
2) Although I admit that FLUID-LET would be the most common way of
obtaining dynamic behavior, I'd rather have it be a simple macro that
expands into a standard procedure. In particular, I would like to
have
(FLUID-LET ((<var-expr1> <val-expr1>)
(<var-expr2> <val-expr2>)
... )
<body>)
expand into something like
(with-cell-contents
(list var-expr1 var-expr2 ...)
(list val-expr1 val-expr2 ...)
(lambda ()
<body>))
I don't object to this in principle, but I'd rather a somewhat simpler
primitive that doesn't promote lists in this way. For example, the
following:
(fluid-let ((<var-expr1> <val-expr1>)
(<var-expr2> <val-expr2>)
...
(<var-exprN> <val-exprN>))
<body>)
expands into
(let ((var1 <var-expr1>)
(val1 <val-expr1>)
(var2 <var-expr2>)
(val2 <val-expr2>)
...
(varN <var-exprN>)
(valN <val-exprN>)
(body-thunk (lambda () <body>)))
(with-fluid-binding var1 val1
(lambda ()
(with-fluid-binding var2 val2
(lambda ()
...
(with-fluid-binding varN valN
body-thunk) ... )))))
That is, I prefer a primitive that establishes exactly one binding at a
time. Also, since I conceive of this construct in terms of new bindings in
the fluid environment, as opposed to changing the ``contents'' of anything,
a prefer a name for the primitive that says so. Thus my
``with-fluid-binding'' in contrast to Jinx's ``with-cell-contents''.
3) There are many incompatible versions of FLUID-LET out there, so I
think we should use a different name for it so that existing
implementations can continue using their code without having to
rewrite it and can provide two different mechanisms, the standard, and
the old one. I would suggest WITH-FLUID-CONTENTS or something like
that, but I'm not good at choosing names.
Cedar Scheme is one of those implementations with an incompatible construct
called FLUID-LET, so we would have to rewrite our code as well, but I don't
anticipate it being very hard to do. It seems to me that a very simple
global query-replace could be used to change all of the uses of the old
construct to use a different name. That way, the new standard construct
can use the stylistically correct and appropriate name and old code need
not be rewritten. For example, we might rename our old construct to
SHALLOW-BIND... (Unlike Scheme Xerox, our new implementation, Cedar Scheme
does not support multiple threads of execution.)
I think it's important, when we reach consensus on a feature with which
we've all experimented, that we can reasonably expect some implementations
to change for the new standard.
================
I believe that the above discussion answers all standing comments on the
fluid binding proposal. Are there any further comments or responses to the
above?
Pavel
∂12-Jul-89 1400 @mc.lcs.mit.edu,@LIFE.ai.mit.edu:cph@zurich.ai.mit.edu scheme mailing list
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 12 Jul 89 14:00:16 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22080;
12 Jul 89 16:51 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jul 89 16:45:56 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21962;
12 Jul 89 16:43 EDT
Received: from ZURICH.AI.MIT.EDU ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA02542; Wed, 12 Jul 89 16:23:08 EDT
Return-Path: <cph@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Wed, 12 Jul 89 16:20:03 edt
Date: Wed, 12 Jul 89 16:20:03 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907122020.AA13254@ZURICH.AI.MIT.EDU>
To: pavel.pa@xerox.com
Cc: scheme-standard@LIFE.ai.mit.edu, rrrs-authors@LIFE.ai.mit.edu
In-Reply-To: Chris Haynes's message of Wed, 12 Jul 89 12:09:16 -0500
Subject: scheme mailing list
Date: Wed, 12 Jul 89 12:09:16 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
Date: Thu, 06 Jul 89 18:52:11 PDT
From: Pavel.pa@Xerox.COM
Chris, can you add someone to the Scheme-Standard mailing list? I've tried
writing to scheme-standard-request@mc.lcs.mit.edu (but it doesn't exist)
and cph@kleph.ai.mit.edu (but got nasty mailer failures).
I'd like to see my summer intern, Jim Rauen <Rauen.pa@Xerox.Com>, have
access to both scheme-standard and rrrs-authors; so far, I haven't managed
to succeed at either of them. Sigh.
Thanks,
Pavel
The correct address is
scheme-standard-request@wheaties.ai.mit.edu
My correct address is
cph@zurich.ai.mit.edu
(recent system reconfiguration prevents "kleph" from accepting mail).
I've added rauen to "scheme-standard".
I have to look into "rrrs-authors" -- JAR left me in charge of it
while he's away.
I've set things up so that the following addresses will work,
forwarding mail to the appropriate mailing lists. I may actually move
the lists to this machine for ease of maintainance.
rrrs-authors@life.ai.mit.edu
rrrs-authors-request@life.ai.mit.edu
scheme@life.ai.mit.edu
scheme-request@life.ai.mit.edu
∂12-Jul-89 1433 @mc.lcs.mit.edu,@decwrl.dec.com:jmiller@crl.dec.com R↑3.95RS: open-input-file open-output-file
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 12 Jul 89 14:33:09 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22672;
12 Jul 89 17:28 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jul 89 17:24:43 EDT
Received: from decwrl.dec.com by mintaka.lcs.mit.edu id aa22596;
12 Jul 89 17:22 EDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
id AA02411; Wed, 12 Jul 89 14:22:24 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
for rrrs-authors@mc.lcs.mit.edu; id AA02411; Wed, 12 Jul 89 14:22:24 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
id AA01036; Tue, 11 Jul 89 13:56:11 EDT
Date: Tue, 11 Jul 89 13:57:19 EDT
From: jmiller@crl.dec.com
Message-Id: <8907111757.AA00833@peanut.DEC.COM>
To: Alan@reagan.ai.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden 10-Jul-89 1709 EDT's message of Tue, 11 Jul 89 03:57:03 EDT <8907110757.AA00450@crl.crl.dec.com>
Subject: R↑3.95RS: open-input-file open-output-file
Reply-To: JMiller@crl.enet.dec.com
I agree completely with you. One of the things that Scheme needs is a
"reasonable" error (condition, exception, take your pick) system. In
lieu of that, which I suspect will take some time to agree upon, I
believe we need a mechanism for PORTABLE programs to use procedures
that SIGNAL an error. There are very few such procedures: only these
two (OPEN-[IN/OUT]PUT-FILE), two similar ones that can be built on top
of these (CALL-WITH-[IN/OUT]PUT-FILE), and READ. In addition, numeric
operations are permitted to signal an error when they reach
implementation limits on representations.
Is it really a high price to pay, pending agreement on an error
system, to allow a portable mechanism for detecting the errors
generated by OPEN-[IN/OUT]PUT-FILE? Notice that my proposal would not
make this the default behavior: only with explicit programmer action
would it be possible to receive a value of #F instead of an error.
Making this change would allow programs, for example, to try
alternative file names given a root file name (this allows porting
across Scheme implementations, not operating systems). A similar
change to READ would allow portable programs to recover from user
input errors.
--Jim
∂12-Jul-89 1444 @mc.lcs.mit.edu,@decwrl.dec.com:jmiller@crl.dec.com EQV? and =
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 12 Jul 89 14:44:37 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22908;
12 Jul 89 17:38 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jul 89 17:24:50 EDT
Received: from decwrl.dec.com by mintaka.lcs.mit.edu id aa22598;
12 Jul 89 17:23 EDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
id AA02503; Wed, 12 Jul 89 14:22:55 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
for rrrs-authors@mc.lcs.mit.edu; id AA02503; Wed, 12 Jul 89 14:22:55 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
id AA01246; Tue, 11 Jul 89 16:54:54 EDT
Date: Tue, 11 Jul 89 16:56:02 EDT
From: jmiller@crl.dec.com
Message-Id: <8907112056.AA00888@peanut.DEC.COM>
To: rrrs-authors@mc.lcs.mit.edu
Subject: EQV? and =
Reply-To: JMiller@crl.enet.dec.com
I thought that
(and (number? x) (number? y) (= x y)) implied
(eqv? x y).
By my reading of R3.95RS this isn't true (consider x=3 and y=3.0),
although I believe
(and (number? x) (number? y) (eqv? x y)) implies
(= x y)
Have I got this right?
--Jim
∂12-Jul-89 1716 @mc.lcs.mit.edu,@life.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 12 Jul 89 17:16:36 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24940;
12 Jul 89 20:12 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jul 89 20:09:01 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24788;
12 Jul 89 20:03 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03806; Wed, 12 Jul 89 20:03:45 EDT
Return-Path: <@spencer.cs.uoregon.edu:will@cs.uoregon.edu>
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Wed, 12 Jul 89 20:00:43 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA20470; Wed, 12 Jul 89 17:03:12 PDT
Received: by spencer.cs.uoregon.edu; Wed, 12 Jul 89 17:03:23 PDT
Date: Wed, 12 Jul 89 17:03:23 PDT
From: will@cs.uoregon.edu
Message-Id: <8907130003.AA17137@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: last call: changes for R4RS
The P1178 working group on Scheme has requested a few more changes to the
R3.95RS before it becomes the R4RS. From the votes taken at P1178, I
judge that two of these changes are sufficiently controversial that they
will require positive action by the authors to be adopted. The other
changes that were requested appear to be noncontroversial, and I will
implement these other changes unless the authors object.
I have promised the P1178 editors that I will deliver the final draft of
the R4RS to them by the end of July so they can incorporate it into the
IEEE standard they're drafting. So if you want to influence the R4RS,
you'd better send mail to RRRS-AUTHORS within the next two weeks.
I will be off the net during that time because my department is moving
into a new building this weekend, and the computers will be shut down
until the move is completed. I have made arrangements to read mail sent
to RRRS-AUTHORS during that time, but I will be unable to send mail myself.
Peace,
William Clinger
(503) 345-6995 (home)
--------------------------------------------------------------------------------
Controversial changes requiring positive action by the authors if they are
to be adopted in the R4RS:
Section 6.3.
P1178 has requested again that LIST-REF be made essential, for parallelism
with VECTOR-REF and STRING-REF. Their previous request that LIST-TAIL be
made essential has been dropped.
Section 6.5.5.
P1178 has requested that MIN and MAX be renamed INF and SUP. The rationale
is that the somewhat surprising behavior of MIN and MAX when given mixed
exact and inexact arguments would be more acceptable if their names were
less familiar. A second rationale is that the fact that the mathematical
infimum and supremum operations, when given an infinite set of "arguments",
may return a result that is not in the argument set; this is the surprising
thing about MIN and MAX, e.g. (MAX 1.4 #e1e100) ==> 9.999999999999998e99.
Background: In any case, a note will be added to point out and explain this
behavior, which is required in order for exact results to be trusted. It
happens that MIN and MAX behave this way in Common Lisp as well, although
the motivation was rather different.
--------------------------------------------------------------------------------
Noncontroversial changes that will be adopted in the R4RS unless the authors
object:
Section 6.5.3.
EXPT will be added to the list of procedures that are required to return
an exact integer if all their arguments are exact and the mathematically
expected result is representable as an exact integer within the
implementation. Examples of what will be newly required:
(expt 2 3) --> 8 ; exact 8
(expt -3 0) --> 1 ; exact 1
(expt 1 -20) --> 1 ; exact 1
Section 6.5.5.
If a variable x has a proper number as its value, then (= x x) will be
required to be true. Note: "proper number" is intended to exclude NaNs
et cetera. [Alternatively we could require NUMBER?---and therefore
REAL?---to be false of NaNs. I'd rather not try to specify this level
of detail until we have more experience with non-IEEE implementations
of inexact arithmetic.]
Section 6.2.
EQV?-ness is preserved when storing into and fetching from the standard
data structures (pairs, vectors, strings). [Note: EQ?-ness isn't
necessarily preserved. Preservation of EQV?-ness implies preservation
of exactness, which is the context in which P1178 requested this change.]
P1178 and individuals also pointed out several places where editorial
changes would improve the presentation, but none of these changes affect
the content so I'm not going to list them here.
--------------------------------------------------------------------------------
Summary of substantive changes that I have posted in previous messages:
Add ... as a new peculiar identifier.
Change branch cuts for ATAN.
Require INTEGER->CHAR and CHAR->INTEGER be one-to-one.
Restore CHAR-UPPER-CASE?.
Make the truth value of the empty list be unspecified.
Fix the second production for <decimal 10>.
Change the specification of NUMBER->STRING to fix bugs pointed out by
Kent Dybvig.
∂12-Jul-89 1731 @mc.lcs.mit.edu,@life.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu legion
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 12 Jul 89 17:31:02 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25119;
12 Jul 89 20:22 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jul 89 20:09:18 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24819;
12 Jul 89 20:06 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03862; Wed, 12 Jul 89 20:05:55 EDT
Return-Path: <@spencer.cs.uoregon.edu:will@cs.uoregon.edu>
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Wed, 12 Jul 89 20:02:56 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA20486; Wed, 12 Jul 89 17:05:28 PDT
Received: by spencer.cs.uoregon.edu; Wed, 12 Jul 89 17:05:39 PDT
Date: Wed, 12 Jul 89 17:05:39 PDT
From: will@cs.uoregon.edu
Message-Id: <8907130005.AA17154@spencer.cs.uoregon.edu>
To: rrrs-authors@ZURICH.ai.mit.edu
Subject: legion
In response to Pavel's sermon/supplication, here is what I think of some
of the ideas that have been mooted about recently.
If indeed we must add fluid variables to the language, then I think that
we should do something very like Pavel's proposal. I'm not keen on
adding fluid variables, however. If we are to add any dynamic features
I'd rather add DYNAMIC-WIND, which seems simpler and more useful. If
we had DYNAMIC-WIND and a macro package, then people could pull their
favorite semantics for fluid variables out of the yellow pages.
Jinx:
...I'll state my position, which I believe coincides with his and
was the consensus of most implementors a while ago.
An implementation that does not allow assignment of the initial
variables (including those bound to procedures) in an RnRs environment
is in ERROR....It is acceptable, however, for an implementation to
default to "benchmark" mode, as long as the following two conditions
are met:
1) There is a way to take it out of benchmark mode.
2) Appropriate warnings about redefinition/warning are given when the
implementation is in benchmark mode and an assignment/redefinition is
"attempted".
I agree with this statement. I would add to it that while the number
of people who need to get out of benchmark mode is very small, they
usually have pretty good reasons for wanting to escape from it.
Furthermore it isn't very hard to design a Scheme system so that the
vast majority of users who run in benchmark mode do not lose any
performance as a result of the tiny minority who need to escape from it.
Pavel:
...The way you'll lose horribly in Scheme Xerox is that your program
won't compile. I'm not asking R4RS to prohibit redefinition, I'm
simply asking it to let me do so in my own implementation.
It is perfectly all right for your compiler to prohibit redefinition,
so long as your system provides a second mode in which redefinition is
allowed. The second mode doesn't have to be fast. It could be
implemented by a pure interpreter layered on top of everything else,
using an entirely separate environment. Furthermore you could require
that users who wish to program in non-benchmark mode must do so by
loading the interpreter interactively and calling a special
read/eval/print loop. In other words, the requirement you've been so
concerned about is absolutely trivial. You should go ahead and build
your system however you want, and implement the non-benchmark mode
after you've got everything else running.
Jinx:
I think most people would agree that R4RS as it currently stands is a
toy language. Besides macros, fluid binding and other well known
conveniences, it lacks any practical way of separating large programs
into semi-independent subprograms without exporting zillions of names
into the top level environment.
I do not agree that R4RS is a toy language. Compare it to C: Scheme's
unrestricted block structure, together with the first-class-ness of all
objects that allows a locally defined object to be stored into a global
variable, provides at least as much control over names as you get with
C. C doesn't have fluid variables, nor does it have environments, nor
does it have EVAL, et cetera. C has macros, but if C's macros are the
decisive feature that makes C a non-toy language then we can trivially
make R4RS into a non-toy language by wedding it to the C preprocessor.
Scheme is deficient in several ways, but we can justify proposed
improvements without characterizing the existing language as a toy.
Pavel:
...the user cannot portably assign to (or even rebind) variables
named ``if'', ``or'', ``delay'', or even ``unquote''...
Morry:
This is one of the reasons we need macros. As soon as we have them,
I will be able to override the default definitions for special forms
as well.
This is speculation, since not all macro facilities allow this override.
Common Lisp provides an example.
Jinx:
We've been trying to fix this for quite a while. It has not been
fixed in R4RS because of political and technical problems having to do
with the actual solutions suggested, not because we don't agree that
this should be fixed.
I am not convinced that it should be fixed. So long as the set of
syntactic keywords is very small, keeping them reserved contributes to
readability. It also appears that the various macro facilities that
have been proposed would be significantly easier to use correctly if
syntactic keywords remain reserved. In fact, I believe that one of
the main reasons we don't yet have a standard macro facility is that
too much effort has been devoted to the difficulties that arise only
when syntactic keywords can be shadowed by lexical variables.
Jim Miller:
I'd like to suggest that Pavel use "|" instead of ":" for his module
separator.
I thought this was an excellent suggestion. In addition to the four
reserved brackets ([, ], {, }), the three varieties of quote mark
(", ', `), and the comma, there are four very usable characters
available for extending the lexical syntax of identifiers: | @ # \.
If an implementation consumes these four and is still hungry for more,
then I doubt we can appease it for long by feeding it a colon.
Will:
2. (This reason is pretty weak.) For the compiler writer, I
think the freedom to rearrange definitions makes closure
analysis a little simpler when procedure definitions are
mixed with definitions of variables containing non-procedure
values.
This is incorrect. The compiler would still have the freedom to move
procedure definitions in front of other definitions, since it could
make a difference only if the program is in error. Once the procedure
definitions have been grouped together, their order makes no difference
under either semantics.
Peace, Will
∂12-Jul-89 1745 @mc.lcs.mit.edu,@life.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu Regularization of list, vector, and string procedures
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 12 Jul 89 17:45:24 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25254;
12 Jul 89 20:32 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jul 89 20:09:33 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24837;
12 Jul 89 20:08 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03872; Wed, 12 Jul 89 20:08:06 EDT
Return-Path: <@spencer.cs.uoregon.edu:will@cs.uoregon.edu>
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Wed, 12 Jul 89 20:05:07 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA20496; Wed, 12 Jul 89 17:07:37 PDT
Received: by spencer.cs.uoregon.edu; Wed, 12 Jul 89 17:07:48 PDT
Date: Wed, 12 Jul 89 17:07:48 PDT
From: will@cs.uoregon.edu
Message-Id: <8907130007.AA17164@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Regularization of list, vector, and string procedures
Cc: mkatz@sesame.stanford.edu
6) String=? is only present for symetry with string-ci=? and should NOT
be generalized to list=? and vector=? since we already have =?.
I think you meant EQUAL? instead of =?.
1) Create list? which checks for a null terminated list...
This is useful. I prefer the name PROPER-LIST?.
2) Generalize apply...[to be generic in the last argument]
I'd prefer to avoid generic procedures at the lowest levels of Scheme.
Why not have LIST-APPLY, VECTOR-APPLY, and STRING-APPLY, by analogy with
LIST-LENGTH, VECTOR-LENGTH, and STRING-LENGTH etc?
3) There are several possibilities for map and foreach:
a) ...
b) Introduce list-map, string-map, vector-map, list-foreach,
string-foreach, and vector-foreach...
c) The same 6 procedures would be introduced as in b). In this
case the name would specify the type of the return value.
The procedures would be polymorphic over arguments of type
list, string, and vector...
In c), it doesn't make sense to have three versions of FOR-EACH distinguished
by the type of their return value, since presumably the return value is
unspecified in each case. Again, I'd prefer type-specific procedures over
generic procedures, because the types are usually known and something like
(VECTOR-FOREACH F V1 V2) conveys more information than (FOREACH F V1 V2).
As a practical matter, the type-specific procedures would have to exist
anyway, and the question is whether the programmer gets to refer to them
directly or must go through a generic interface that obscures the type
information.
The argument in favor of generic procedures is that there would have to be
3 type-specific versions of FOR-EACH and 9 type-specific versions of MAP
even if all the arguments to these procedures are required to be of the
same type. It gets worse if we relax that requirement or if we add more
sequence types.
Here's a counter-proposal: define MAKE-FOREACH and MAKE-MAP that take a
description of the argument and result types for the FOR-EACH or MAP
procedure needed and return the appropriate FOR-EACH or MAP procedure.
Implementations would then be free to special-case these procedures as much
as they feel is necessary, using EQ? tests on the arguments. Sample
implementation and use of MAKE-MAP:
>>> (define (make-map maker0 setter0 length1 ref1 . more-length&ref-procs)
(do ((length-procs (list length1) (cons (car procs) length-procs))
(ref-procs (list ref1) (cons (cadr procs) ref-procs))
(procs more-length&ref-procs (cddr more-length&ref-procs)))
((null? procs)
(let ((length-procs (reverse length-procs))
(ref-procs (reverse ref-procs)))
(lambda (f x1 . more-args)
(let ((args (cons x1 more-args))
(n (length1 x1)))
(for-each (lambda (length-proc arg)
(if (not (= (length-proc arg) n))
(error "Arguments have different lengths")))
(cdr length-procs)
(cdr args))
(let ((result (maker0 n)))
(do ((i (- n 1) (- i 1)))
((negative? i) result)
(setter0 result i (apply f (map (lambda (ref arg)
(ref arg i))
ref-procs
args)))))))))))
make-map
>>> (define map:string&list->vector
(make-map make-vector vector-set!
string-length string-ref
length list-ref))
map:string&list->vector
>>> (map:string&list->vector list "abcdef" '(0 1 2 3 4 5))
#((#\a 0) (#\b 1) (#\c 2) (#\d 3) (#\e 4) (#\f 5))
This proposal is substantially more general than generic MAP or FOR-EACH
would be (since the length, ref, and setter procedures could perform
arbitrary computations), and could be made equally efficient for the
cases that could be handled by generic MAP and generic FOR-EACH.
Peace, Will
∂12-Jul-89 2216 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #157
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 12 Jul 89 22:16:32 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa29664;
13 Jul 89 0:58 EDT
Date: 13 JUL 89 00:10:56 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #157
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907130058.aa29664@mintaka.lcs.mit.edu>
Scheme Digest #157 13 JUL 89 00:10:56 EDT
Today's Topics:
DO syntax in XScheme
do loop for 1.6 XScheme
----------------------------------------------------------------------
Date: Wed, 12 Jul 89 16:46:56 GMT
From: NETWORK%FRSAC11.BITNET@mitvma.mit.edu
Subject: DO syntax in XScheme
Message-ID: <8907121059.aa12607@mintaka.lcs.mit.edu>
I am looking deseparatly for a do construct for XSCHEME, 0.15 or 0.16.
The change in macros.s between 0.15 and 0.16 break my
syntax for named-lambda. Any comments or working named-lambda in 0.16 ?
The benchmarks give a noticeable slowdown from 0.15 to 0.16, any comments ?
Any understandable documentation on the macro.s package welcome.
I need the ststuff.c for the atari ST, using MWC, by the way.
I made up something to work with Lattice 3.04, but it may be less than ideal.
Regards,
Jean-Pierre H. Dumas
network@frsac11 (bitnet)
network%frsac11.bitnet@cunyvm.cuny.edu (arpanet)
dumas@sumex-aim.stanford.edu (arpanet)
------------------------------
Date: 12 Jul 89 21:19:40 GMT
From: Shawn McLean <news!mclean@think.com>
Subject: re: do loop for 1.6 XScheme
Message-Id: <MCLEAN.89Jul12171940@pozzo.think.com>
Help yourself. Also included is a defsetf clone. -shawn
;;; (c) Copyright 1989, Shawn Mclean
;;; All rights reserved
;;; Permission is granted for unrestricted non-commercial use
;;; created: Tue 3-28-1989 22:32
;;; XScheme - Version 0.16
;;; commonlisp compatibility macros and functions
;;;
;;; macros
;;;
(macro defmacro
(lambda (form)
(let* ((name (cadr form)) (form (cddr form))
(arglist (car form)) (form (cdr form))
(body (car form)))
(put name '%arglist arglist)
`(macro ,name
(lambda (form)
(apply (lambda ,arglist ,body) (cdr form)))))))
;;;
;;; lists
;;;
(macro first (lambda (form) `(car ,(cadr form))))
(macro second (lambda (form) `(cadr ,(cadr form))))
(macro third (lambda (form) `(caddr ,(cadr form))))
(macro fourth (lambda (form) `(cadddr ,(cadr form))))
(macro fifth (lambda (form) `(caddddr ,(cadr form))))
(macro nth (lambda (form) `(list-ref ,(cadr form) ,(caddr form))))
(macro push
(lambda (form)
(let ((item (cadr form))
(list (caddr form)))
`(set! ,list (cons ,item ,list)))))
(macro pop
(lambda (form)
(let ((list (cadr form))
(item (gensym 'item)))
`(let ((,item (car ,list)))
(set! ,list (cdr ,list))
,item))))
;;;
;;; loops
;;;
(macro do
(lambda (form)
(let (locals test body exits inits updates)
(set! locals (reverse (cadr form)))
(set! form (cddr form))
(set! test (car form))
(set! form (cdr form))
(set! body form)
(set! exits (cdr test))
(set! test (list 'not (car test)))
(while locals
(let* ((local (car locals))
(var (if (list? local) (car local) local))
(init (cadr local))
(update (caddr local)))
(push (list var init) inits)
(if update (push `(set! ,var ,update) updates))
(set! locals (cdr locals))))
`(let ,inits (while ,test ,@body ,@updates) ,@exits))))
(macro do*
(lambda (form)
(let (locals test body exits inits updates)
(set! locals (reverse (cadr form)))
(set! form (cddr form))
(set! test (car form))
(set! form (cdr form))
(set! body form)
(set! exits (cdr test))
(set! test (list 'not (car test)))
(while locals
(let* ((local (car locals))
(var (if (list? local) (car local) local))
(init (cadr local))
(update (caddr local)))
(push (list var init) inits)
(if update (push `(set! ,var ,update) updates))
(set! locals (cdr locals))))
`(let* ,inits (while ,test ,@body ,@updates) ,@exits))))
(macro dotimes
(lambda (form)
(let* ((control (cadr form))
(body (cddr form))
(var (car control))
(limit (cadr control)))
`(let ((,var 0))
(while (< ,var ,limit) ,@body (set! ,var (1+ ,var)))))))
(macro dolist
(lambda (form)
(let* ((control (cadr form))
(body (cddr form))
(item (car control))
(list (cadr control))
(items (gensym 'items)))
`(let ((,items ,list))
(while (not (null? ,items))
(set! ,item (car ,items))
,@body
(set! ,items (cdr ,items)))))))
;;;
;;; debugger
;;;
;;; Is this the way to do this?
(define break
(lambda args
(display "break: ") (dolist (arg (cdr args)) (display arg))
(let ((env (environment-bindings (the-environment))))
(dolist (binding env)
(map display (car binding) ": " (cdr binding))
(newline))
(read))))
;;;
;;; string conversions
;;; not common lisp
(define integer->string
(lambda (integer)
(let ((done nil) (integer-string nil))
(while (not done)
(push (integer->char (+ (char->integer #\0) (remainder integer 10)))
integer-string)
(set! integer (quotient integer 10))
(set! done (= integer 0)))
(list->string integer-string))))
;;;
;;; general accessor
;;;
;;; This is a defsetf clone that works on global functions. A modifier
;;; function is first defined with defset, and following set will invert a
;;; reference. For example:
;;;
;;; (set (car foo) 'bar) => (set-car! foo 'bar)
;;;
;;; If anything, this saves you from typing !'s all over the place. set
;;; will accept one or pairs of auguments.
(macro set
(lambda (pairs)
(if (odd? (length (cdr pairs)))
(error "odd number of arguments to set")
(do* ((place (cdr pairs) (cdr place))
(value (cdr place) (cdr place))
(assignments nil))
((null? place)
(if (cdr assignments)
`(begin ,@(reverse assignments))
(car assignments)))
(set! assignments (cons (general-set (car place) (car value))
assignments))
(set! place (cdr place))))))
(define general-set
(lambda (place value)
(if (list? place)
((get (car place) 'set) (cadr place) value)
`(set! ,place ,value))))
(defmacro defset (function lambda-list values form)
(let ((set-function `(lambda (,@lambda-list ,@values) ,form)))
`(begin (put ',function 'set ,set-function) ',function)))
(defset car (list) (value) `(set-car! ,list ,value))
(defset cdr (list) (value) `(set-cdr! ,list ,value))
------------------------------
End of Scheme Digest
********************
∂13-Jul-89 0537 @mc.lcs.mit.edu,@life.ai.mit.edu:ramsdell@linus.mitre.org fluid variables
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 05:37:00 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04407;
13 Jul 89 8:34 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 08:30:46 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa04309;
13 Jul 89 8:28 EDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02056; Thu, 13 Jul 89 08:28:17 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA22160; Thu, 13 Jul 89 08:24:46 EDT
Posted-Date: Thu, 13 Jul 89 08:24:40 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA02866; Thu, 13 Jul 89 08:24:40 EDT
Date: Thu, 13 Jul 89 08:24:40 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8907131224.AA02866@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Wed, 12 Jul 89 17:05:39 PDT <8907130005.AA17154@spencer.cs.uoregon.edu>
Subject: fluid variables
Reply-To: ramsdell@mitre.org
I support the general idea adding fluid variables to Scheme. We
should face the fact that current-input-port and current-output-port
really should be fluid variables, and define with-input-from-file and
with-output-to-file in terms of fluid-let and call-with-input-file and
call-with-output-file.
I will withdraw my support if implementors feel fluid variables would
slow down their Scheme implementation.
John
∂13-Jul-89 1137 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 11:36:52 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09942;
13 Jul 89 14:14 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 14:08:56 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09681;
13 Jul 89 14:00 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00494; Thu, 13 Jul 89 14:00:13 EDT
Received: from life.ai.mit.edu (ai.mit.edu) by zurich.ai.mit.edu; Thu, 13 Jul 89 13:57:13 edt
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA05014; Thu, 13 Jul 89 11:57:23 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA27346; Thu, 13 Jul 89 08:56:23 PDT
Date: Thu, 13 Jul 89 08:56:23 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907131556.AA27346@sesame.Stanford.EDU>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Wed, 12 Jul 89 17:03:23 PDT <8907130003.AA17137@spencer.cs.uoregon.edu>
Subject: last call: changes for R4RS
Date: Wed, 12 Jul 89 17:03:23 PDT
From: will@cs.uoregon.edu
Section 6.3.
P1178 has requested again that LIST-REF be made essential, for parallelism
with VECTOR-REF and STRING-REF. Their previous request that LIST-TAIL be
made essential has been dropped.
I have said it beofre, but just to make my position clear, I support the
inclusion of LIST-REF in R4RS if the rest of the proposal for regularization of
sting, vector, and list procedures is adopted; and, I oppose it, otherwise.
Section 6.5.5.
P1178 has requested that MIN and MAX be renamed INF and SUP.
Personally, I prefer the names MIN nad MAX despite the infinum and supremum
semantics. But, I do not feel stonrgly enough about this to put up much of an
argument.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂13-Jul-89 1141 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu Regularization of list, vector, and string procedures
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 11:41:43 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa10119;
13 Jul 89 14:23 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 14:09:10 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09685;
13 Jul 89 14:00 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00497; Thu, 13 Jul 89 14:00:24 EDT
Received: from life.ai.mit.edu (ai.mit.edu) by zurich.ai.mit.edu; Thu, 13 Jul 89 13:57:25 edt
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA04957; Thu, 13 Jul 89 11:49:38 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA27294; Thu, 13 Jul 89 08:48:35 PDT
Date: Thu, 13 Jul 89 08:48:35 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907131548.AA27294@sesame.Stanford.EDU>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Wed, 12 Jul 89 17:07:48 PDT <8907130007.AA17164@spencer.cs.uoregon.edu>
Subject: Regularization of list, vector, and string procedures
Date: Wed, 12 Jul 89 17:07:48 PDT
From: will@cs.uoregon.edu
6) String=? is only present for symetry with string-ci=? and should NOT
be generalized to list=? and vector=? since we already have =?.
I think you meant EQUAL? instead of =?.
Correct. RNRS changed between the tie I wrote the initial message (about 1
year ago) and when I reposted it.
1) Create list? which checks for a null terminated list...
This is useful. I prefer the name PROPER-LIST?.
For symetry with STRING? and VECTOR?, I think it should be called LIST? even
though PROPER-LIST? would be a better name in the absence of these
considerations.
2) Generalize apply...[to be generic in the last argument]
I'd prefer to avoid generic procedures at the lowest levels of Scheme.
Why not have LIST-APPLY, VECTOR-APPLY, and STRING-APPLY, by analogy with
LIST-LENGTH, VECTOR-LENGTH, and STRING-LENGTH etc?
I must be suffering from brain damage. This is clearly a better idea and more
in keeping with the spirit of my other recommendations.
3) There are several possibilities for map and foreach:
a) ...
b) Introduce list-map, string-map, vector-map, list-foreach,
string-foreach, and vector-foreach...
c) The same 6 procedures would be introduced as in b). In this
case the name would specify the type of the return value.
The procedures would be polymorphic over arguments of type
list, string, and vector...
In c), it doesn't make sense to have three versions of FOR-EACH distinguished
by the type of their return value, since presumably the return value is
unspecified in each case. Again, I'd prefer type-specific procedures over
generic procedures, because the types are usually known and something like
(VECTOR-FOREACH F V1 V2) conveys more information than (FOREACH F V1 V2).
As a practical matter, the type-specific procedures would have to exist
anyway, and the question is whether the programmer gets to refer to them
directly or must go through a generic interface that obscures the type
information.
The argument in favor of generic procedures is that there would have to be
3 type-specific versions of FOR-EACH and 9 type-specific versions of MAP
even if all the arguments to these procedures are required to be of the
same type. It gets worse if we relax that requirement or if we add more
sequence types.
Here's a counter-proposal: define MAKE-FOREACH and MAKE-MAP that take a
description of the argument and result types for the FOR-EACH or MAP
procedure needed and return the appropriate FOR-EACH or MAP procedure.
Implementations would then be free to special-case these procedures as much
as they feel is necessary, using EQ? tests on the arguments. Sample
implementation and use of MAKE-MAP:
>>> (define (make-map maker0 setter0 length1 ref1 . more-length&ref-procs)
(do ((length-procs (list length1) (cons (car procs) length-procs))
(ref-procs (list ref1) (cons (cadr procs) ref-procs))
(procs more-length&ref-procs (cddr more-length&ref-procs)))
((null? procs)
(let ((length-procs (reverse length-procs))
(ref-procs (reverse ref-procs)))
(lambda (f x1 . more-args)
(let ((args (cons x1 more-args))
(n (length1 x1)))
(for-each (lambda (length-proc arg)
(if (not (= (length-proc arg) n))
(error "Arguments have different lengths")))
(cdr length-procs)
(cdr args))
(let ((result (maker0 n)))
(do ((i (- n 1) (- i 1)))
((negative? i) result)
(setter0 result i (apply f (map (lambda (ref arg)
(ref arg i))
ref-procs
args)))))))))))
make-map
>>> (define map:string&list->vector
(make-map make-vector vector-set!
string-length string-ref
length list-ref))
map:string&list->vector
>>> (map:string&list->vector list "abcdef" '(0 1 2 3 4 5))
#((#\a 0) (#\b 1) (#\c 2) (#\d 3) (#\e 4) (#\f 5))
This proposal is substantially more general than generic MAP or FOR-EACH
would be (since the length, ref, and setter procedures could perform
arbitrary computations), and could be made equally efficient for the
cases that could be handled by generic MAP and generic FOR-EACH.
As I implied in my original message, I did not really like the alternatives I
was presenting. On the other hand, I thing Will's suggestion is a good one.
I, for one, put my stamp of approval on this proposal. Additionally, I would
suggest that MAP and FOREACH remain bound to their current values for backward
compatibility.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂13-Jul-89 1156 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 11:56:17 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa10332;
13 Jul 89 14:36 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 14:16:03 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09175;
13 Jul 89 13:41 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00297; Thu, 13 Jul 89 13:40:59 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Thu, 13 Jul 89 13:26:05 edt
Received: from fafnir.think.com by Think.COM; Thu, 13 Jul 89 13:19:49 EDT
Received: from verdi.think.com by fafnir.think.com; Thu, 13 Jul 89 13:18:16 EDT
Received: by verdi.think.com; Thu, 13 Jul 89 13:18:12 EDT
Date: Thu, 13 Jul 89 13:18:12 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907131718.AA13175@verdi.think.com>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Wed, 12 Jul 89 17:03:23 PDT <8907130003.AA17137@spencer.cs.uoregon.edu>
Subject: last call: changes for R4RS
Date: Wed, 12 Jul 89 17:03:23 PDT
From: will@cs.uoregon.edu
...
Section 6.5.5.
P1178 has requested that MIN and MAX be renamed INF and SUP. The rationale
is that the somewhat surprising behavior of MIN and MAX when given mixed
exact and inexact arguments would be more acceptable if their names were
less familiar. A second rationale is that the fact that the mathematical
infimum and supremum operations, when given an infinite set of "arguments",
may return a result that is not in the argument set; this is the surprising
thing about MIN and MAX, e.g. (MAX 1.4 #e1e100) ==> 9.999999999999998e99.
Background: In any case, a note will be added to point out and explain this
behavior, which is required in order for exact results to be trusted. It
happens that MIN and MAX behave this way in Common Lisp as well, although
the motivation was rather different.
I find this proposal quite startling. The objection is that MIN and MAX
don't work properly, and therefore the solution is not to correct their
behavior but to change their names!?
The first rationale is bogus. INF and SUP are standard mathematic
terminology. It is clearly not a question of the terminology as such being
more or less familiar; one can only perhaps say that they are familiar to
fewer people. This is an advantage? Those who do know what INF and SUP are
supposed to mean will only be confused in exactly the same way by the faulty
behavior; those who do not know what they mean are likely to read the
description and then internalize them as "Oh, they are just like MIN and MAX,
only with funny names."
The second rationale is fallacious. Indeed INF (resp. SUP) may return values
not in the set of arguments, but such result is guaranteed to be larger
(resp. smaller) than any of the arguments. The example given fails to have
this property, and renaming MIN and MAX to INF and SUP will not repair the
problem.
Note that Common Lisp does not require MIN and MAX to have faulty
behavior; it merely permits it. When comparing a rational and a float,
MIN and MAX may either apply floating-point contagion and then compare
(leading to possible anomalies), or treat the float as exact and possibly
return the rational, not converted to a float.
The problem is that MIN (or INF) is supposed to return the largest value that
is no smaller than any argument, and currently it fails to do so in Scheme.
So why not just say it that way? Change the definition of MIN and MAX.
Don't give them new names that will have the same problem.
--Guy
∂13-Jul-89 1202 @mc.lcs.mit.edu,@life.ai.mit.edu:Alan@REAGAN.ai.mit.edu legion
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 12:01:53 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11183;
13 Jul 89 14:45 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 14:22:39 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa10062;
13 Jul 89 14:21 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00745; Thu, 13 Jul 89 14:20:57 EDT
Received: from REAGAN.AI.MIT.EDU (reagan.ai.mit.edu) by zurich.ai.mit.edu; Thu, 13 Jul 89 14:17:51 edt
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 235316; Thu 13-Jul-89 13:38:32 EDT
Date: Thu, 13 Jul 89 13:38 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Subject: legion
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: <8907130005.AA17154@spencer.cs.uoregon.edu>
Message-Id: <19890713173826.2.ALAN@PIGPEN.AI.MIT.EDU>
Date: Wed, 12 Jul 89 17:05:39 PDT
From: will@cs.uoregon.edu
...
Pavel:
...the user cannot portably assign to (or even rebind) variables
named ``if'', ``or'', ``delay'', or even ``unquote''...
...
Jinx:
We've been trying to fix this for quite a while. It has not been
fixed in R4RS because of political and technical problems having to do
with the actual solutions suggested, not because we don't agree that
this should be fixed.
I am not convinced that it should be fixed. So long as the set of
syntactic keywords is very small, keeping them reserved contributes to
readability.
Isn't this an argument against having macros at all? Perhaps you have
always been opposed to macros and I never caught on? Or perhaps I don't
understand your notion of "reserved":
It also appears that the various macro facilities that
have been proposed would be significantly easier to use correctly if
syntactic keywords remain reserved.
I suppose that if by "syntactic keywords remain reserved" you mean that I
am not allowed to introduce any new ones, then indeed all macro facilities
are equally easy to use -- because then you aren't allows to define any
macros at all! Or perhap you draw some kind of distinction between
"syntactic keywords" (that only implementors can create) and "macros" (that
users define)? Like perhaps I am not allowed to shadow IF, while I am
allowed to shadow PUSH (assuming PUSH is a macro that I myself defined)? I
fail to see how this kind of distinction could contribute to anything
except confusion.
In fact, I believe that one of
the main reasons we don't yet have a standard macro facility is that
too much effort has been devoted to the difficulties that arise only
when syntactic keywords can be shadowed by lexical variables.
I completely disagree. I believe that one of the advantages of syntactic
closures is that it solves this problem using exactly the same mechanism it
uses to solve the problems of ordinary lexical variable shadowing. The
"difficulties that arise only when syntactic keywords can be shadowed by
lexical variables" are subdued with no additional "effort" whatsoever.
This issue has nothing to do with why we don't have a standard macro
facility.
∂13-Jul-89 1233 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com Correction
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 12:33:07 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12614;
13 Jul 89 15:14 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 15:10:26 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12295;
13 Jul 89 15:04 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01670; Thu, 13 Jul 89 15:04:48 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Thu, 13 Jul 89 15:01:52 edt
Received: from fafnir.think.com by Think.COM; Thu, 13 Jul 89 15:04:46 EDT
Received: from verdi.think.com by fafnir.think.com; Thu, 13 Jul 89 15:03:12 EDT
Received: by verdi.think.com; Thu, 13 Jul 89 15:03:05 EDT
Date: Thu, 13 Jul 89 15:03:05 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907131903.AA13779@verdi.think.com>
To: gls@think.com
Cc: will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Guy Steele's message of Thu, 13 Jul 89 13:18:12 EDT <8907131718.AA13175@verdi.think.com>
Subject: Correction
Date: Thu, 13 Jul 89 13:18:12 EDT
From: Guy Steele <gls@Think.COM>
...
The second rationale is fallacious. Indeed INF (resp. SUP) may return values
not in the set of arguments, but such result is guaranteed to be larger
(resp. smaller) than any of the arguments. ...
Sorry--that should have read "smaller (resp. larger)". Editing error.
--Guy
∂13-Jul-89 1238 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Fluid binding
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 12:38:26 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12895;
13 Jul 89 15:24 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 15:16:05 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12538;
13 Jul 89 15:11 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01893; Thu, 13 Jul 89 15:11:36 EDT
Received: from life.ai.mit.edu (ai.mit.edu) by zurich.ai.mit.edu; Thu, 13 Jul 89 15:08:23 edt
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA01156; Thu, 13 Jul 89 05:37:32 EDT
Received: from hpda.HP.COM by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA29989; Thu, 13 Jul 89 02:21:05 pdt
Received: from hpesogg (hpesogr) by hpda.HP.COM; Thu, 13 Jul 89 02:21:47 pdt
Message-Id: <8907130921.AA28558@hpda.HP.COM>
Received: by hpesogg; Thu, 13 Jul 89 02:20:39 pdt
Date: Thu, 13 Jul 89 02:20:39 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@hpesogg.hp.com
In-Reply-To: Pavel.pa@xerox.com's message of Wed, 12 Jul 89 11:00:52 PDT
Subject: Fluid binding
Reply-To: jinx%hpda@sde.hp.com
1) MAKE-FLUID, FLUID-REF and FLUID-SET! don't have much to do with
fluids, they have to do with cells (or boxes, as some other people
call them). As such, I would like them to be renamed to
MAKE-CELL, CELL-REF, and CELL-SET!.
Alternatively we could have both MAKE-CELL, CELL-REF, CELL-SET! to
manipulate cells (the selector and mutator always provide the global
value), and FLUID-CELL-REF, FLUID-CELL-SET! to access the current
dynamic value. Which of the accessors is written on top of which
depends on whether the implementation is deep or shallow.
When I first read this, it seemed very reasonable. On later thought,
however, I concluded otherwise. For the first paragraph, I think that,
conceptually, MAKE-FLUID, FLUID-REF and FLUID-SET! have nothing to do with
cells at all. Rather, they traffic in ``fluid variables'', opaque values
that are the domain of the ``fluid environment'' (the range is locations,
just as in the lexical environment). Certainly one implementation of these
procedures (and the one I would use) has MAKE-FLUID return a cell, as you
suggest, but I think renaming them in terms of cells is a convolution of
their abstract semantics with one particular concrete realization.
I think calling these objects fluid "variables" in the context of
other Scheme variables is very misleading. Lexical (ordinary) Scheme
variables can't be aliased, since their addresses cannot be passed
around. These can. Lexical variables can only be affected by special
forms, these can be affected (and usually are) by procedures. Lexical
variables are not first class, they are not even objects since they
are not expressible values. Yours are first class objects. It seems
to me that these fluid variables are much more similar to pairs than
to anything else in the language.
Let's put it another way. In the absence of FLUID-LET, what is the
difference between your fluids and 1-slot records? Your
interpretation is that there is a lot of hair in fluid environments,
etc. Mine is simpler: there are cells, and there is a special form
which establishes a temporary/isolated contents for them. Except for
efficiency, there is no reason why that could not be generalized to
pairs, vectors, etc.
I have additional problems with idea in the second paragraph. In a
shallow-binding implementation, CELL-REF is identical to FLUID-CELL-REF
while in a deep-binding implementation, their semantics is quite different.
I think it unwise for the language semantics to change depending upon a
property of the implementation that should be completely invisible.
The proposal was not completely serious, but you misunderstood it
anyway.
The semantics of these procedures would be the same whether the
implementation was shallow or deep. They would be implemented
differently, and which set was primitive would also vary.
In a shallow implementation, FLUID-CELL-REF and FLUID-CELL-SET! would
be the procedures which merely dereferenced/mutated the cell, and
CELL-REF and CELL-SET! would be implemented on top of them.
In a deep implementation, CELL-REF and CELL-SET! would be the
primitive forms, and the fluid versions would be implemented on top
of them.
In either case, the fluid forms would access/mutate the current fluid
location, while the non-fluid forms would access the global location,
which is not the same as the physical cell. The physical cell could
be accessed/mutated by %CELL-REF and %CELL-SET! which would be one of
the sets, depending on the implementation. I did not suggest adding
the % procedures because they (and only they) are implementation
dependent.
I don't object to this in principle, but I'd rather a somewhat simpler
primitive that doesn't promote lists in this way. For example, the
following:
(fluid-let ((<var-expr1> <val-expr1>)
(<var-expr2> <val-expr2>)
...
(<var-exprN> <val-exprN>))
<body>)
expands into
(let ((var1 <var-expr1>)
(val1 <val-expr1>)
(var2 <var-expr2>)
(val2 <val-expr2>)
...
(varN <var-exprN>)
(valN <val-exprN>)
(body-thunk (lambda () <body>)))
(with-fluid-binding var1 val1
(lambda ()
(with-fluid-binding var2 val2
(lambda ()
...
(with-fluid-binding varN valN
body-thunk) ... )))))
That is, I prefer a primitive that establishes exactly one binding at a
time. Also, since I conceive of this construct in terms of new bindings in
the fluid environment, as opposed to changing the ``contents'' of anything,
a prefer a name for the primitive that says so. Thus my
``with-fluid-binding'' in contrast to Jinx's ``with-cell-contents''.
No problem, except with the name. I was just suggesting that there
should be a basic procedure in terms of which FLUID-LET could be
expanded.
Cedar Scheme is one of those implementations with an incompatible construct
called FLUID-LET, so we would have to rewrite our code as well, but I don't
anticipate it being very hard to do. It seems to me that a very simple
global query-replace could be used to change all of the uses of the old
construct to use a different name. That way, the new standard construct
can use the stylistically correct and appropriate name and old code need
not be rewritten. For example, we might rename our old construct to
SHALLOW-BIND... (Unlike Scheme Xerox, our new implementation, Cedar Scheme
does not support multiple threads of execution.)
Your solution assumes that you can reach all code that used FLUID-LET.
That is unlikely in a wide-spread implementation.
A second objection is purely based on the name. I don't think that
FLUID-LET is a very appropriate name for your form, since it is (in my
mind, where all you are doing is data structure manipulation)
unrelated to LET. I'd much rather have your form be called ISOLATE,
TEMPORARILY, or something like that.
∂13-Jul-89 1446 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 14:46:20 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16307;
13 Jul 89 17:22 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 17:04:27 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa15743;
13 Jul 89 17:03 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA00499; Thu, 13 Jul 89 17:03:15 EDT
Received: from localhost by zurich.ai.mit.edu; Thu, 13 Jul 89 17:00:18 edt
Date: Thu, 13 Jul 89 17:00:18 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907132100.AA22760@zurich.ai.mit.edu>
To: gls@think.com
Cc: will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Guy Steele's message of Thu, 13 Jul 89 13:18:12 EDT <8907131718.AA13175@verdi.think.com>
Subject: last call: changes for R4RS
Date: Thu, 13 Jul 89 13:18:12 EDT
From: Guy Steele <gls@think.com>
I find this proposal quite startling. The objection is that MIN and MAX
don't work properly, and therefore the solution is not to correct their
behavior but to change their names!?
[...]
The problem is that MIN (or INF) is supposed to return the largest value that
is no smaller than any argument, and currently it fails to do so in Scheme.
So why not just say it that way? Change the definition of MIN and MAX.
Don't give them new names that will have the same problem.
--Guy
I disagree with the statements in these paragraphs because they
presume a definition of "proper" that I believe is incorrect.
All of this boils down to the meaning of `<', which is very poorly
defined for inexact numbers. Because of this I don't believe that
statements like "don't work properly" and "fails to do so in Scheme"
can be applied here: given a fuzzy definition of `<' on inexact
numbers we are forced to accept a fuzzy definition of "largest" and
"smaller" as well, which further forces us to accept that the result
of `min' will be "correct" (by the definition above) modulo all the
fuzz. This is different from it being correct in a mathematical
sense, but then, that is what the inexactness stuff is all about
anyway.
On the other hand, the above definition will normally hold, except
when inexact numbers are involved AND some implementation limit is
reached, in which case the arithmetic is specifically allowed to
return an inexact number which is mathematically incorrect; then it is
the user's responsibility to deal with the "incorrect" answer.
Perhaps a simpler solution to the whole problem is to add a prominent
warning note, like the one attached to `<' and friends, that warns
about the unreliability of `max' and `min' when inexact numbers are in
use.
∂13-Jul-89 1520 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 15:20:08 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17466;
13 Jul 89 18:11 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 18:06:40 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa17285;
13 Jul 89 18:03 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01319; Thu, 13 Jul 89 18:03:48 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Thu, 13 Jul 89 18:00:51 edt
Received: from fafnir.think.com by Think.COM; Thu, 13 Jul 89 18:03:50 EDT
Received: from verdi.think.com by fafnir.think.com; Thu, 13 Jul 89 18:02:12 EDT
Received: by verdi.think.com; Thu, 13 Jul 89 18:02:10 EDT
Date: Thu, 13 Jul 89 18:02:10 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907132202.AA14486@verdi.think.com>
To: cph@zurich.ai.mit.edu
Cc: gls@think.com, will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Chris Hanson's message of Thu, 13 Jul 89 17:00:18 edt <8907132100.AA22760@zurich.ai.mit.edu>
Subject: last call: changes for R4RS
Date: Thu, 13 Jul 89 17:00:18 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Date: Thu, 13 Jul 89 13:18:12 EDT
From: Guy Steele <gls@think.com>
I find this proposal quite startling. The objection is that MIN and MAX
don't work properly, and therefore the solution is not to correct their
behavior but to change their names!?
[...]
The problem is that MIN (or INF) is supposed to return the largest value that
is no smaller than any argument, and currently it fails to do so in Scheme.
So why not just say it that way? Change the definition of MIN and MAX.
Don't give them new names that will have the same problem.
--Guy
I disagree with the statements in these paragraphs because they
presume a definition of "proper" that I believe is incorrect.
All of this boils down to the meaning of `<', which is very poorly
defined for inexact numbers. Because of this I don't believe that
statements like "don't work properly" and "fails to do so in Scheme"
can be applied here: given a fuzzy definition of `<' on inexact
numbers we are forced to accept a fuzzy definition of "largest" and
"smaller" as well, which further forces us to accept that the result
of `min' will be "correct" (by the definition above) modulo all the
fuzz. This is different from it being correct in a mathematical
sense, but then, that is what the inexactness stuff is all about
anyway.
On the other hand, the above definition will normally hold, except
when inexact numbers are involved AND some implementation limit is
reached, in which case the arithmetic is specifically allowed to
return an inexact number which is mathematically incorrect; then it is
the user's responsibility to deal with the "incorrect" answer.
Perhaps a simpler solution to the whole problem is to add a prominent
warning note, like the one attached to `<' and friends, that warns
about the unreliability of `max' and `min' when inexact numbers are in
use.
Fine. I am happy to agree with everything you say, and your final
suggestion is indeed probably the best solution. The blame can be laid on
<, or on inexactness, if you wish. My main point still stands: WHATEVER
the fundamental difficulty, or wherever you wish to place the blame, simply
renaming the functions to INF and SUP does not solve the problem; the
rationales advanced to support the renaming remain bogus.
--Guy
∂13-Jul-89 1537 @mc.lcs.mit.edu,@LIFE.ai.mit.edu:gjs@hpesogg.hp.com last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 15:37:12 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17712;
13 Jul 89 18:22 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 18:12:24 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa17477;
13 Jul 89 18:11 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01377; Thu, 13 Jul 89 18:11:20 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Thu, 13 Jul 89 18:08:22 edt
Received: from hpda.HP.COM by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA15414; Thu, 13 Jul 89 15:10:58 pdt
Received: from hpesogg (hpcup18) by hpda.HP.COM; Thu, 13 Jul 89 15:08:35 pdt
Message-Id: <8907132208.AA24978@hpda.HP.COM>
Received: by hpesogg; Thu, 13 Jul 89 15:07:27 pdt
Date: Thu, 13 Jul 89 15:07:27 pdt
From: Gerald Jay Sussman <gjs@hpesogg.hp.com>
To: cph@zurich.ai.mit.edu
Cc: gls@think.com, will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Chris Hanson's message of Thu, 13 Jul 89 17:00:18 edt <8907132100.AA22760@zurich.ai.mit.edu>
Subject: last call: changes for R4RS
You say:
Perhaps a simpler solution to the whole problem is to add a prominent
warning note, like the one attached to `<' and friends, that warns
about the unreliability of `max' and `min' when inexact numbers are in
use.
I agree with your suggestion completely. It is consistent with
everything else we are doing to do it that way. We don't change the
name of "+" to make it less misleading, we warn about the possible
problems and limitations that appear.
∂13-Jul-89 1622 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 16:22:02 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18935;
13 Jul 89 19:16 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 19:13:04 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa18724;
13 Jul 89 19:05 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01904; Thu, 13 Jul 89 19:05:45 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Thu, 13 Jul 89 19:02:41 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA29641; Thu, 13 Jul 89 16:04:41 PDT
Date: Thu, 13 Jul 89 16:04:41 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907132304.AA29641@sesame.Stanford.EDU>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Wed, 12 Jul 89 17:03:23 PDT <8907130003.AA17137@spencer.cs.uoregon.edu>
Subject: last call: changes for R4RS
ciao,
In the section entitled Procedure calls (4.1.3):
"The operator and operand expressions are evaluated (in an indeterminate order)
and the resulting procedure is passed the resulting arguments."
Is the intention here that the order can be any order as long as it is either
"right-to left" or "left-to-right" or is an implementation truely free to use
any order (which could lead to interleaving on a multi-process implementation)?
(peace chance)
mas
∂13-Jul-89 1635 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Confusion
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 16:35:04 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19225;
13 Jul 89 19:26 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 19:13:19 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa18782;
13 Jul 89 19:08 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01922; Thu, 13 Jul 89 19:08:10 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Thu, 13 Jul 89 19:05:13 edt
Received: from hpda.HP.COM by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA16657; Thu, 13 Jul 89 16:07:40 pdt
Received: from hpesogg (hpesogr) by hpda.HP.COM; Thu, 13 Jul 89 16:05:58 pdt
Message-Id: <8907132305.AA01682@hpda.HP.COM>
Received: by hpesogg; Thu, 13 Jul 89 16:04:39 pdt
Date: Thu, 13 Jul 89 16:04:39 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: willc@cs.uoregon.edu
Cc: gls@think.com, rrrs-authors@hpesogg.hp.com
Subject: Confusion
Reply-To: jinx%hpda@sde.hp.com
I'm confused about a lot of things. Perhaps I should have read Will's
original message more carefully, rather than assume that I knew what
was going on.
P1178 has requested that MIN and MAX be renamed INF and SUP. The rationale
is that the somewhat surprising behavior of MIN and MAX when given mixed
exact and inexact arguments would be more acceptable if their names were
less familiar. A second rationale is that the fact that the mathematical
infimum and supremum operations, when given an infinite set of "arguments",
may return a result that is not in the argument set; this is the surprising
thing about MIN and MAX, e.g. (MAX 1.4 #e1e100) ==> 9.999999999999998e99.
Background: In any case, a note will be added to point out and explain this
behavior, which is required in order for exact results to be trusted. It
happens that MIN and MAX behave this way in Common Lisp as well, although
the motivation was rather different.
As far as I understand it (and GJS agrees with me), the example Will
shows could only be correct in an implementation where
(>= 9.999999999999998e99 #e1e100) is true. If it isn't, the
implementation of MAX/SUP is in error.
If (>= 9.999999999999998e99 #e1e100) holds, then it is not surprising
that MAX/SUP returns 9.999999999999998e99. Perhaps users of such an
implementation should flame at the implementor of >= or of the numeric
printing routine.
The rationale for the renaming these procedures is that MAX and MIN
have a common connotation of returning one of the elements of the
input set. Clearly these procedures don't do this. They are more
like the mathematical definition of SUP and INF which are defined to
return the smallest value >= (or <=) than any of the input parameters.
A different way to look at this is that numbers are not ordered in a
line, but in a lattice. Along the exact and the inexact dimension,
the results are as expected, but when mixing them, we look for the SUP
(INF) in the lattice, so again, the names make sense.
The second rationale is fallacious. Indeed INF (resp. SUP) may return values
not in the set of arguments, but such result is guaranteed to be larger
(resp. smaller) than any of the arguments. The example given fails to have
this property, and renaming MIN and MAX to INF and SUP will not repair the
problem.
The problem is that MIN (or INF) is supposed to return the largest value that
is no smaller than any argument, and currently it fails to do so in Scheme.
So why not just say it that way? Change the definition of MIN and MAX.
Don't give them new names that will have the same problem.
The rationale is not fallacious if you understand that larger or
smaller mean >= and <=, not the expected >= and <= that you compute by
looking at the printed representation. On a good implementation these
two notions of >= should be very close.
If the implementation returns true to the query
(>= 9.999999999999998e99 #e1e100), it is consistent, and is doing what
you expect (modulo it's poor definition of >= or of number->string).
∂13-Jul-89 1721 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 17:21:02 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19850;
13 Jul 89 19:47 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 19:39:48 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa19529;
13 Jul 89 19:35 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA02199; Thu, 13 Jul 89 19:35:13 EDT
Received: from localhost by zurich.ai.mit.edu; Thu, 13 Jul 89 19:32:16 edt
Date: Thu, 13 Jul 89 19:32:16 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907132332.AA23738@zurich.ai.mit.edu>
To: shaff@sesame.stanford.edu
Cc: will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Mike Shaff's message of Thu, 13 Jul 89 16:04:41 PDT <8907132304.AA29641@sesame.Stanford.EDU>
Subject: last call: changes for R4RS
Date: Thu, 13 Jul 89 16:04:41 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
ciao,
In the section entitled Procedure calls (4.1.3):
"The operator and operand expressions are evaluated (in an indeterminate order)
and the resulting procedure is passed the resulting arguments."
Is the intention here that the order can be any order as long as it is either
"right-to left" or "left-to-right" or is an implementation truely free to use
any order (which could lead to interleaving on a multi-process implementation)?
(peace chance)
mas
Certainly the implementation is free to use any SEQUENTIAL order.
It has never been clear to me whether the specification permits
simultaneous evaluation of two different arguments.
∂13-Jul-89 1726 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 17:25:56 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20401;
13 Jul 89 19:56 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 19:50:40 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa19803;
13 Jul 89 19:45 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02291; Thu, 13 Jul 89 19:45:08 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Thu, 13 Jul 89 19:42:04 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA29795; Thu, 13 Jul 89 16:43:26 PDT
Date: Thu, 13 Jul 89 16:43:26 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907132343.AA29795@sesame.Stanford.EDU>
To: jinx%hpda@sde.hp.com
Cc: will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Thu, 13 Jul 89 16:29:25 pdt <8907132333.AA03563@hpda.HP.COM>
Subject: last call: changes for R4RS
ciao,
In an almost immediate response from both Jinx and Chris:
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
Any sequential order is the intention. Interleaving should not be
allowed because there are no locking primitives to serialize side
effects.
The MIT Scheme compiler chooses an order that it thinks is convenient
for any given combination, but will not interleave the computation
(unless interleaving does not make a difference).
From: cph@zurich.ai.mit.edu (Chris Hanson)
Certainly the implementation is free to use any SEQUENTIAL order.
It has never been clear to me whether the specification permits
simultaneous evaluation of two different arguments.
This being the case (and presuming this is the generally agreed thinking)
shouldn't this choice be made more explicit. I think the absence of said
locking primitives (at the current time) is an issue whose ramifications should
be noted.
(peace chance)
mas
∂13-Jul-89 1734 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: evaluation order
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 17:34:01 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20762;
13 Jul 89 20:05 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 19:55:58 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20133;
13 Jul 89 19:54 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02362; Thu, 13 Jul 89 19:54:12 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Thu, 13 Jul 89 19:51:13 edt
Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 89 16:38:06 PDT
Date: Thu, 13 Jul 89 16:39:54 PDT
From: Pavel.pa@xerox.com
Subject: Re: evaluation order
In-Reply-To: <8907132304.AA29641@sesame.Stanford.EDU>
To: Mike Shaff <shaff@sesame.stanford.edu>
Cc: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890713-163806-2604@Xerox>
I believe the intent is that the operator and operands are evaluated one at
a time in some order. The order need not be either right-to-left or
left-to-right. You can, in some cases, perform the evaluation in parallel,
but the result must be ``serializable'', to steal a term from transaction
systems; that is, the effect must be indistinguishable from some
non-parallel, non-interleaved evaluation.
Pavel
∂13-Jul-89 1747 @mc.lcs.mit.edu,@LIFE.ai.mit.edu:jinx@hpesogg.hp.com last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 17:47:28 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21151;
13 Jul 89 20:20 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 19:34:32 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa19431;
13 Jul 89 19:33 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02185; Thu, 13 Jul 89 19:33:21 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Thu, 13 Jul 89 19:30:16 edt
Received: from hpda.HP.COM by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA17182; Thu, 13 Jul 89 16:32:47 pdt
Received: from hpesogg (hpesogr) by hpda.HP.COM; Thu, 13 Jul 89 16:33:15 pdt
Message-Id: <8907132333.AA03563@hpda.HP.COM>
Received: by hpesogg; Thu, 13 Jul 89 16:29:25 pdt
Date: Thu, 13 Jul 89 16:29:25 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: shaff@sesame.stanford.edu
Cc: will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Mike Shaff's message of Thu, 13 Jul 89 16:04:41 PDT <8907132304.AA29641@sesame.Stanford.EDU>
Subject: last call: changes for R4RS
Reply-To: jinx%hpda@sde.hp.com
ciao,
In the section entitled Procedure calls (4.1.3):
"The operator and operand expressions are evaluated (in an indeterminate order)
and the resulting procedure is passed the resulting arguments."
Is the intention here that the order can be any order as long as it is either
"right-to left" or "left-to-right" or is an implementation truely free to use
any order (which could lead to interleaving on a multi-process implementation)?
(peace chance)
mas
Any sequential order is the intention. Interleaving should not be
allowed because there are no locking primitives to serialize side
effects.
The MIT Scheme compiler chooses an order that it thinks is convenient
for any given combination, but will not interleave the computation
(unless interleaving does not make a difference).
∂13-Jul-89 1756 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@bloom.la.tek.com Re: last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 17:56:30 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21557;
13 Jul 89 20:39 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 20:35:55 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21436;
13 Jul 89 20:31 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02735; Thu, 13 Jul 89 20:31:39 EDT
Received: from RELAY.CS.NET (relay.cs.net) by zurich.ai.mit.edu; Thu, 13 Jul 89 20:28:40 edt
Received: from tektronix.tek.com by RELAY.CS.NET id aa10349; 13 Jul 89 18:55 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA28581; Thu, 13 Jul 89 15:57:27 PDT
Received: by dadla.LA.TEK.COM (5.51/6.24)
id AA18298; Thu, 13 Jul 89 15:51:04 PDT
Received: by bloom.LA.TEK.COM (1.2/6.24)
id AA01721; Thu, 13 Jul 89 15:55:52 pdt
Message-Id: <8907132255.AA01721@bloom.LA.TEK.COM>
To: Guy Steele <gls@think.com>
Cc: cph@zurich.ai.mit.edu, will%cs.uoregon.edu@relay.cs.net,
rrrs-authors@zurich.ai.mit.edu
Subject: Re: last call: changes for R4RS
In-Reply-To: Your message of Thu, 13 Jul 89 18:02:10 EDT.
<8907132202.AA14486@verdi.think.com>
Date: 13 Jul 89 15:55:47 PDT (Thu)
From: kend%bloom.la.tek.com@relay.cs.net
Guy says:
.. renaming the functions to INF and SUP does not solve the problem...
The point in the renaming is not to change a suprising behavior, but
to warn that the specified behavior is not in accord with the `simple'
behavior `expected' from MIN and MAX. The IEEE draft expects to cross
reference MAX to SUP and MIN to INF in the index and point out potential
suprises caused by the definitions involved so that a user expecting
algebraic laws to hold is educated to a more refined model with respect to
the realities of machine arithmetic.
-Ken Dickey kend@mrloog.LA.TEK.COM
∂13-Jul-89 1812 @mc.lcs.mit.edu,@life.ai.mit.edu:andy@ads.com Arg evaluation order
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 18:12:20 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21742;
13 Jul 89 20:50 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 20:47:01 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21614;
13 Jul 89 20:42 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02865; Thu, 13 Jul 89 20:42:47 EDT
Received: from hobbes.ads.com ([128.229.32.19]) by zurich.ai.mit.edu; Thu, 13 Jul 89 20:39:48 edt
Received: by hobbes.ads.com (5.59/1.11)
id AA00370; Thu, 13 Jul 89 17:39:34 PDT
Date: Thu, 13 Jul 89 17:39:34 PDT
From: Andy Cromarty <andy@ads.com>
Message-Id: <8907140039.AA00370@hobbes.ads.com>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Arg evaluation order
Cc: andy@ads.com, jinx%hpda@sde.hp.com
MAS writes:
In the section entitled Procedure calls (4.1.3):
"The operator and operand expressions are evaluated (in an
indeterminate order) and the resulting procedure is passed
the resulting arguments."
Is the intention here that the order can be any order as
long as it is either "right-to left" or "left-to-right" or
is an implementation truely free to use any order (which
could lead to interleaving on a multi-process
implementation)?
Jinx replies:
Any sequential order is the intention. Interleaving should not be
allowed because there are no locking primitives to serialize side
effects.
The MIT Scheme compiler chooses an order that it thinks is convenient
for any given combination, but will not interleave the computation
(unless interleaving does not make a difference).
This response surprised and, upon reflection, baffled me sufficiently
to raise me out of my torpor. If we do not specify an evaluation
order, what would be the purpose of requiring sequentiality for
evaluation order? This would seem to have the principal "benefit"
of permitting explicitly nonportable code to be written, in that any
reliance on evaluation order on the part of the programmer is
guaranteed to be implementation-specific.
If evaluation order is desirable, shouldn't we specify it? If it is
undesirable or an area of legitimate experimentation (which position
I favor), shouldn't we leave it entirely unspecified, so that
compiler writers may experiment with it freely? As a programmer, I
might well wish to interleave evaluations in an indeterminate way;
and locking or other appropriate means of achieving serialization
can be imposed by the compiler for the multiprocessor, in those
cases where the programmer "requests" it by using existing
primitives for specifying sequential evaluation. (Note that we
already have constructs that can be used to impose sequentiality,
e.g. to order side-effecting operations--- including at least LAMBDA
bodies, the LET-family bodies, DO bodies, COND, CASE, and BEGIN.)
asc
∂13-Jul-89 1820 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Arg evaluation order
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 18:20:52 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21932;
13 Jul 89 21:02 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 20:58:03 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21811;
13 Jul 89 20:55 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02971; Thu, 13 Jul 89 20:55:11 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Thu, 13 Jul 89 20:52:14 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA19542; Thu, 13 Jul 89 17:54:49 pdt
Message-Id: <8907140054.AA19542@sde.hp.com>
Received: by hpesogg; Thu, 13 Jul 89 17:53:42 pdt
Date: Thu, 13 Jul 89 17:53:42 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: andy@ads.com
Cc: rrrs-authors@zurich.ai.mit.edu, andy@ads.com
In-Reply-To: Andy Cromarty's message of Thu, 13 Jul 89 17:39:34 PDT <8907140039.AA00370@hobbes.ads.com>
Subject: Arg evaluation order
Reply-To: jinx%hpesogg@sde.hp.com
This response surprised and, upon reflection, baffled me sufficiently
to raise me out of my torpor. If we do not specify an evaluation
order, what would be the purpose of requiring sequentiality for
evaluation order? This would seem to have the principal "benefit"
of permitting explicitly nonportable code to be written, in that any
reliance on evaluation order on the part of the programmer is
guaranteed to be implementation-specific.
If evaluation order is desirable, shouldn't we specify it? If it is
undesirable or an area of legitimate experimentation (which position
I favor), shouldn't we leave it entirely unspecified, so that
compiler writers may experiment with it freely? As a programmer, I
might well wish to interleave evaluations in an indeterminate way;
and locking or other appropriate means of achieving serialization
can be imposed by the compiler for the multiprocessor, in those
cases where the programmer "requests" it by using existing
primitives for specifying sequential evaluation. (Note that we
already have constructs that can be used to impose sequentiality,
e.g. to order side-effecting operations--- including at least LAMBDA
bodies, the LET-family bodies, DO bodies, COND, CASE, and BEGIN.)
The problem is that there are perfectly portable sequential programs
which work when ANY sequential order is used, but not when
interleaved. Consider, for example,
(define (count-nodes! graph-node)
(if (node-marked? graph-node)
0
(begin
(node-mark! graph-node)
(1+ (if (node-leaf? graph-node)
0
(+ (count-nodes! (node-left graph-node))
(count-nodes! (node-right graph-node))))))))
And now think of what happens when a node has the same (eq?) left and
right components, and the arguments to + are interleaved.
∂13-Jul-89 1925 @mc.lcs.mit.edu,@life.ai.mit.edu:andy@ads.com Re: Arg evaluation order
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 19:25:48 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa23489;
13 Jul 89 22:16 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 22:13:07 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa23305;
13 Jul 89 22:08 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03672; Thu, 13 Jul 89 22:08:10 EDT
Received: from hobbes.ads.com ([128.229.32.19]) by zurich.ai.mit.edu; Thu, 13 Jul 89 22:05:11 edt
Received: by hobbes.ads.com (5.59/1.11)
id AA00427; Thu, 13 Jul 89 19:06:39 PDT
Date: Thu, 13 Jul 89 19:06:39 PDT
From: Andy Cromarty <andy@ads.com>
Message-Id: <8907140206.AA00427@hobbes.ads.com>
To: jinx%hpesogg@sde.hp.com
Subject: Re: Arg evaluation order
Cc: andy@ads.com, rrrs-authors@zurich.ai.mit.edu
Jinx writes:
The problem is that there are perfectly portable sequential programs
which work when ANY sequential order is used, but not when
interleaved. Consider, for example,
(define (count-nodes! graph-node)
(if (node-marked? graph-node)
0
(begin
(node-mark! graph-node)
(1+ (if (node-leaf? graph-node)
0
(+ (count-nodes! (node-left graph-node))
(count-nodes! (node-right graph-node))))))))
And now think of what happens when a node has the same (eq?) left and
right components, and the arguments to + are interleaved.
So let's see. I infer you are walking a binary cyclic digraph
(otherwise the node-mark! procedure isn't needed), in a
multiprocessor shared-memory environment (otherwise there's no race
condition to resolve). (Knowing this, you might trivially solve
the problem with an atomic test-and-set replacing node-marked? and
node-mark!, but this is cheating, given my suggestion that implicit
serialization should be enough with the compiler generating the
needed serialization code).
Now, a compiler should be able trivially to determine that node-mark!
is a (potential) mutator, and hence that count-nodes! is a mutator;
thus determining that there is a race condition just in case
(eq? (node-left graph-node) (node-right graph-node))
is straightforward, although it's admittedly potentially expensive
for a compiler to test for in general (but that's the compiler-writer's
business, isn't it, and perhaps the compiler executes combinatorically
quickly on the same multiprocessor for which it generates code). Of course,
once the compiler has determined that there is a race condition, there
is nothing to prevent it from generating code that serializes the
evaluation of +'s args---in any order it deems convenient at the
time. It even could produce code that tests the eq?-ness of +'s
args and serializes conditionally; this seems to work, although it
has the weakness that it is combinatorically expensive to test for
race conditions of all left's vs. all right's (needed just in case one
processor executes + faster than another). But a sufficiently "smart"
compiler also might be able to determine when the graph structure in
question is "small" and will not be grown during execution, in which
case the combinatoric cost of completely checking eq?-ness
(especially if it's just once per graph) is uncompelling and concurrent
unserialized execution could be a win in cases where no cells of the graph
are found to be eq?, especially where (say) node-leaf? is a relatively
expensive operation to perform. (This cost-comparison example is somewhat
strained, but then I didn't get to choose the example application. :-)
Note that under the interpretation I proposed, nothing prevents you
from writing a compiler that happens to serialize in whatever order
you find moral, whereas under your intepretation, I might be prohibited
from experimenting with compilers that leave the evaluation order
undefined and make their own decisions about evaluation ordering
dynamically. Also, it is possible (I'm not sure) that your
counterexample begs the question of whether we automatically should
expect "old" sequential code always to run on a shared-memory
multiprocessor without rethinking or redesigning the code.
Apart from the incidental convenience this offers, I'm not sure why
that would be a reasonable expectation, any more than (say) we would
expect IBM/360 assembler code to run on a Sun. Perhaps it's enough to
expect that code written for languages *designed* to execute in both
environments (e.g. FORTRAN-66, for the example of the 360 and Sun) need
no redesign; in my view Scheme presently does not qualify as a language
explicitly designed to work both in uniprocessor and shared-memory
multiprocessor environments. (After all, we still have people advocating
that a construct named WHEN, with all its colloquial intuitive appeal for
capturing time dependency, be [opinion warning:] wasted as syntactic sugar
for IF.)
asc
∂13-Jul-89 2140 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Arg evaluation order
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 21:40:38 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27568;
14 Jul 89 0:29 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Jul 89 00:25:00 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa27410;
14 Jul 89 0:18 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01280; Fri, 14 Jul 89 00:18:40 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Fri, 14 Jul 89 00:15:44 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA22738; Thu, 13 Jul 89 21:18:23 pdt
Message-Id: <8907140418.AA22738@sde.hp.com>
Received: by hpesogg; Thu, 13 Jul 89 21:17:49 pdt
Date: Thu, 13 Jul 89 21:17:49 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: andy@ads.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Andy Cromarty's message of Thu, 13 Jul 89 19:06:39 PDT <8907140206.AA00427@hobbes.ads.com>
Subject: Arg evaluation order
Reply-To: jinx%hpesogg@sde.hp.com
So let's see. I infer you are walking a binary cyclic digraph
(otherwise the node-mark! procedure isn't needed), in a
multiprocessor shared-memory environment (otherwise there's no race
condition to resolve). (Knowing this, you might trivially solve
the problem with an atomic test-and-set replacing node-marked? and
node-mark!, but this is cheating, given my suggestion that implicit
serialization should be enough with the compiler generating the
needed serialization code).
This has nothing to do with parallel processing or race conditions, it
has to do with enforcing the consistency of data structures. If the
language allows interleaved evaluation, there is nothing that prevents
a compiler for a SEQUENTIAL implementation from interleaving the
calls, by open coding, for example, and ignore the interaction between
tests and side effects on "different" branches of the computation.
Now, a compiler should be able trivially to determine that node-mark!
is a (potential) mutator, and hence that count-nodes! is a mutator;
thus determining that there is a race condition just in case
(eq? (node-left graph-node) (node-right graph-node))
is straightforward, although it's admittedly potentially expensive
....
Your argument suffers from two common bugs:
1) The "infinitely smart compiler" bug.
2) Separate compilation (not applicable to my simple example), which means
that the compiler can hardly ever tell anything about side effects
between two operands.
Besides, what are you really arguing? It seems that you are saying
that the current requirement is fine, since a sufficiently smart
compiler will be able to take advantage of interleaving in those cases
where it won't compromise the sematics.
Please, let's make the "infinitely smart compiler" optional, and have
it do a little extra work when it wants to interleave, rather than
allow interleaving in the sequential language, eliminating
predictability.
Note that under the interpretation I proposed, nothing prevents you
from writing a compiler that happens to serialize in whatever order
you find moral, whereas under your intepretation, I might be prohibited
from experimenting with compilers that leave the evaluation order
undefined and make their own decisions about evaluation ordering
dynamically.
That is correct. If you are designing a parallel language, you will
have to specify in which way I can control the evaluation, but that
takes you outside of Scheme. Such a language would NOT be Scheme.
Let's not put everything and the kitchen sink into this language.
∂13-Jul-89 2211 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #158
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 22:11:13 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27730;
14 Jul 89 0:39 EDT
Date: 14 JUL 89 00:11:00 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #158
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907140039.aa27730@mintaka.lcs.mit.edu>
Scheme Digest #158 14 JUL 89 00:11:00 EDT
Today's Topics:
Opening files with Cscheme
----------------------------------------------------------------------
Date: 13 Jul 89 18:36:08 GMT
From: Les Milash <unicads!les@boulder.colorado.edu>
Subject: Opening files with Cscheme
Message-Id: <553@unicads.UUCP>
i have a thing called CScheme, which i love. i have a manual called
RRRS. i have a problem.
i'm trying to write a program that's c-preprocessor compatable, in that
it takes a -I/parameter -I/that/lists/a/bunch -I/of/directories/that
include files might be in. so when the code includes foo.h i have to
find the first one of
/parameter/foo.h
/that/lists/a/bunch/foo.h
/of/directories/that/foo.h
that exists.
RRRS talks about (open-input-file "filename") but if the file doesn't exist
i get an "out of range with "filename"" error and the program stops.
is there a way to figure out if some file exists without crashing? or
some way to substitute some better error behaviour (i'd just as soon
have it return '() or #!the-you-screwed-up-object or something).
i have the CScheme source and am not adverse to making myself un-scheme-
compatable (but i imagine that scheme can do what i want somehow (else
what good is it?))
thanks in advance for the assistance!
Les Milash
wow! with a language like this, i might even be able to handle
a shared-memory multiprocessor!
------------------------------
End of Scheme Digest
********************
∂14-Jul-89 0433 @mc.lcs.mit.edu,@life.ai.mit.edu:gjs@hpesogg.hp.com D. Press, Ing.
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 14 Jul 89 04:33:29 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04164;
14 Jul 89 7:23 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Jul 89 07:20:29 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa04097;
14 Jul 89 7:15 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03750; Fri, 14 Jul 89 07:15:51 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Fri, 14 Jul 89 07:12:54 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA06325; Fri, 14 Jul 89 04:15:32 pdt
Message-Id: <8907141115.AA06325@sde.hp.com>
Received: by hpesogg; Fri, 14 Jul 89 04:14:57 pdt
Date: Fri, 14 Jul 89 04:14:57 pdt
From: Gerald Jay Sussman <gjs@hpesogg.hp.com>
To: rrrs-authors@hpesogg.hp.com
Subject: D. Press, Ing.
A rather exercised character, D. Press, Ing. has been following the
activity of the Scheme mailing list. He has communicated to us the
following commentary on the recent controversies.
GJS & HAL
I'm confused about the unreliability of `max' and `min' when inexact
numbers are not ordered in a line, but in a lattice. Along the exact
and inexact arguments would be more acceptable if their names were
less familiar. A second rationale is that the fact that the
mathematical infimum and supremum operations--- including at least
LAMBDA bodies, the LET-family bodies, DO not specify an indeterminate
order) and the resulting procedure is cheating, given my suggestion
that implicit serialization should be enough with an atomic
test-and-set replacing node-marked? and node-mark! is a (potential)
mutator, and hence that count-nodes! is a mutator; thus determining
that there is convenient for any given combination, but will not
interleave the computation (unless interleaving does not make a
difference).
The point in the renaming is not to change a compiler should be able
trivially to determine that node-mark! is a (potential) mutator, and
now think of what happens when a node has the same (eq?) left" or of
the numeric printing routine.
The rationale is that the somewhat surprising behavior of MIN and MAX
when given mixed exact and inexact arguments would be more acceptable
if their names were less familiar. A second rationale is that the
somewhat surprising behavior of MIN and MAX when given mixed exact and
inexact arguments to + are interleaved.
So let's see. I infer you are walking a common connotation of
returning one of the elements of what happens when a node has the
problem...
A second rationale is that the fact that the mathematical infimum and
supremum operations, when given an infinite set of "arguments", may
return a result that is not in the argument set; this is cheating,
given my suggestion that implicit serialization should be enough with
your suggestion completely. A second rationale is that the fact that
the mathematical infimum and supremum operations, when given an
infinite set of "arguments", may return a result that is not in the
argument set; this is cheating, given my suggestion that implicit
serialization should be enough with your suggestion completely.
"The operator and, upon reflection, baffled me sufficiently to raise
me out of my simple example), which means that the compiler can hardly
ever tell anything about side effects between tests and renaming MIN
and MAX to INF and SUP will not repair the problem is that there are
perfectly portable sequential programs which work when ANY sequential
order is the intention. Interleaving should not be allowed because
there are you really arguing? It seems that you are saying that the
current requirement is fine, since a sufficiently smart compiler will
be able to take advantage of interleaving in those cases where it
won't compromise the sematics.
D. Press, Ing.
∂14-Jul-89 0903 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu Released Report
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 14 Jul 89 09:03:22 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07281;
14 Jul 89 11:58 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Jul 89 11:54:32 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07215;
14 Jul 89 11:53 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06100; Fri, 14 Jul 89 11:53:19 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Fri, 14 Jul 89 11:50:17 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA03006; Fri, 14 Jul 89 08:52:29 PDT
Date: Fri, 14 Jul 89 08:52:29 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907141552.AA03006@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Released Report
ciao,
Will writes:
I have promised the P1178 editors that I will deliver the final draft of
the R4RS to them by the end of July so they can incorporate it into the
IEEE standard they're drafting. So if you want to influence the R4RS,
you'd better send mail to RRRS-AUTHORS within the next two weeks.
I am definitely in favor of moving forward on issues and getting the report out
to the public, however the latest version of the report that I have (via
zurich) still seems to have some areas that I thought were to be part of the
document (per L&FP such things as macros, name regularization, etc were to be
'rubber stamped' by the group). Is there to be another beta release *before*
the submission to P1178? If not, what happened to those and other favorites?
(peace chance)
mas
∂15-Jul-89 0907 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu Released Report
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89 09:07:36 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02656;
15 Jul 89 11:51 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Jul 89 11:54:32 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07215;
14 Jul 89 11:53 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06100; Fri, 14 Jul 89 11:53:19 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Fri, 14 Jul 89 11:50:17 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA03006; Fri, 14 Jul 89 08:52:29 PDT
Date: Fri, 14 Jul 89 08:52:29 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907141552.AA03006@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Released Report
ciao,
Will writes:
I have promised the P1178 editors that I will deliver the final draft of
the R4RS to them by the end of July so they can incorporate it into the
IEEE standard they're drafting. So if you want to influence the R4RS,
you'd better send mail to RRRS-AUTHORS within the next two weeks.
I am definitely in favor of moving forward on issues and getting the report out
to the public, however the latest version of the report that I have (via
zurich) still seems to have some areas that I thought were to be part of the
document (per L&FP such things as macros, name regularization, etc were to be
'rubber stamped' by the group). Is there to be another beta release *before*
the submission to P1178? If not, what happened to those and other favorites?
(peace chance)
mas
∂15-Jul-89 0933 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #159
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89 09:33:35 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02876;
15 Jul 89 12:12 EDT
Date: 15 JUL 89 12:01:47 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #159
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907151212.aa02876@mintaka.lcs.mit.edu>
Scheme Digest #159 15 JUL 89 12:01:47 EDT
Today's Topics:
Opening files with Cscheme
----------------------------------------------------------------------
Date: Fri, 14 Jul 89 10:38:49 edt
From: Chris Hanson <cph@altdorf.ai.mit.edu>
Message-Id: <8907141438.AA01871@altdorf.ai.mit.edu>
Subject: Opening files with Cscheme
Date: 13 Jul 89 18:36:08 GMT
From: Les Milash <unicads!les@boulder.colorado.edu>
i have a thing called CScheme, which i love. i have a manual called
RRRS. i have a problem.
is there a way to figure out if some file exists without crashing?
The procedure `file-exists?' does what you want. It takes a single
argument which is a filename.
------------------------------
End of Scheme Digest
********************
∂15-Jul-89 1102 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Arg evaluation order
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89 11:02:35 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03930;
15 Jul 89 13:17 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jul 89 12:44:32 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa00388;
14 Jul 89 14:44 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08472; Fri, 14 Jul 89 14:44:38 EDT
Received: from life.ai.mit.edu (ai.mit.edu) by zurich.ai.mit.edu; Fri, 14 Jul 89 14:41:35 edt
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA07930; Fri, 14 Jul 89 14:09:18 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA14308; Fri, 14 Jul 89 11:08:31 pdt
Message-Id: <8907141808.AA14308@sde.hp.com>
Received: by hpesogg; Fri, 14 Jul 89 11:07:53 pdt
Date: Fri, 14 Jul 89 11:07:53 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: sfk@sknight.hpl.hp.com
Cc: andy@ads.com, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Steve Knight's message of Fri, 14 Jul 89 9:59:35 BST <8907140903.AA18355@otter.hpl.hp.com>
Subject: Arg evaluation order
Reply-To: jinx%hpesogg@sde.hp.com
From: Steve Knight <sfk@sknight.hpl.hp.com>
Date: Fri, 14 Jul 89 9:59:35 BST
X-Mailer: Elm [version 2.0 beta]
> This has nothing to do with parallel processing or race conditions, it
> has to do with enforcing the consistency of data structures.
I agree on this point. Permitting arguments to be evaluated in arbitrary
order makes the compiler writer's life easier at the expense of the language
user. The belief that this compromise is acceptable stems from two sources, I
think.
1. many other languages specify the absence of an evaluation order,
2. the loss of efficiency when evaluation order is specified.
However, this ambiguity gives rise to a distinct class of potential program
defects.
Steve
I think you are confusing two different possibilities here:
1) Not specifying the order of argument evaluation, but requiring
arguments to be evaluated sequentially. Let's call this option
"reordering" of argument evaluation.
2) Allowing interleaving of argument evaluation, ie. evaluate part of
one, then part of another, then part of yet another, then go back to
the first and continue, etc. Let's called this "interleaving" of
argument evaluation.
The current report allows reordering, but not interleaving. Andy was
asking for the language either to pick a particular order or to allow
interleaving.
The main reason for not specifying an order of argument evaluation is
not the loss of efficiency, but rather to discourage programs that
depend on any particular order, since they are at best obscure. Some
of the hardest bugs to find that I have had to deal with arose from
depending on the order of argument evaluation.
Note that current implementations differ in the way they evaluate
their arguments. Most evaluate left to right, but the MIT Scheme
interpreter, for example, evaluates from right to left. Agreeing on a
particular order, besides undesirable, would probably be politically
infeasible at this point.
I also dispute your statement that the compiler writer's job becomes
easier if arguments can be evaluated in any order. It is certainly
easier (although sometimes less efficient) to pick a particular order
and stick to it. Most compilers do this, and they turn out perfectly
efficient code. On the other hand, if the language does not specify
the order of argument evaluation, deciding when reordering is allowed
becomes trivial.
∂15-Jul-89 1210 @mc.lcs.mit.edu,@LIFE.ai.mit.edu:gls@think.com [postmaster@ames.UUCP: Returned mail: User unknown]
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89 12:10:26 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04564;
15 Jul 89 14:04 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jul 89 12:53:15 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa02145;
14 Jul 89 16:54 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01025; Fri, 14 Jul 89 16:54:55 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Fri, 14 Jul 89 15:54:44 edt
Received: from fafnir.think.com by Think.COM; Fri, 14 Jul 89 15:57:44 EDT
Received: from verdi.think.com by fafnir.think.com; Fri, 14 Jul 89 15:56:13 EDT
Received: by verdi.think.com; Fri, 14 Jul 89 15:56:12 EDT
Date: Fri, 14 Jul 89 15:56:12 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907141956.AA19181@verdi.think.com>
To: rrrs-authors@ZURICH.ai.mit.edu
Subject: [postmaster@ames.UUCP: Returned mail: User unknown]
Date: Fri, 14 Jul 89 12:53:30 -0700
From: Mail Delivery Subsystem <postmaster@ames.UUCP>
Subject: Returned mail: User unknown
To: gls@think.UUCP
----- Transcript of session follows -----
550 rrrs-authors... User unknown
----- Unsent message follows -----
Received: by ames.arc.nasa.gov (5.61/1.2); Fri, 14 Jul 89 12:53:30 -0700
Received: from verdi.think.com by news.think.com; Fri, 14 Jul 89 15:53:56 EDT
Received: by verdi.think.com; Fri, 14 Jul 89 15:51:27 EDT
Date: Fri, 14 Jul 89 15:51:27 EDT
>From: think!gls (Guy Steele)
Message-Id: <8907141951.AA19139@verdi.think.com>
To: ames!sde.hp.com!hplabs!jinx%hpda
Cc: willc@cs.uoregon.edu, think!gls, ames!rrrs-authors
In-Reply-To: Guillermo J. Rozas's message of Thu, 13 Jul 89 16:04:39 pdt <8907132305.AA01682@hpda.HP.COM>
Subject: Confusion
Date: Thu, 13 Jul 89 16:04:39 pdt
From: Guillermo J. Rozas <hplabs!hpesogg!jinx@ames.UUCP>
I'm confused about a lot of things. Perhaps I should have read Will's
original message more carefully, rather than assume that I knew what
was going on.
P1178 has requested that MIN and MAX be renamed INF and SUP. The rationale
is that the somewhat surprising behavior of MIN and MAX when given mixed
exact and inexact arguments would be more acceptable if their names were
less familiar. A second rationale is that the fact that the mathematical
infimum and supremum operations, when given an infinite set of "arguments",
may return a result that is not in the argument set; this is the surprising
thing about MIN and MAX, e.g. (MAX 1.4 #e1e100) ==> 9.999999999999998e99.
Background: In any case, a note will be added to point out and explain this
behavior, which is required in order for exact results to be trusted. It
happens that MIN and MAX behave this way in Common Lisp as well, although
the motivation was rather different.
As far as I understand it (and GJS agrees with me), the example Will
shows could only be correct in an implementation where
(>= 9.999999999999998e99 #e1e100) is true. If it isn't, the
implementation of MAX/SUP is in error.
If (>= 9.999999999999998e99 #e1e100) holds, then it is not surprising
that MAX/SUP returns 9.999999999999998e99. Perhaps users of such an
implementation should flame at the implementor of >= or of the numeric
printing routine.
The rationale for the renaming these procedures is that MAX and MIN
have a common connotation of returning one of the elements of the
input set. Clearly these procedures don't do this. They are more
like the mathematical definition of SUP and INF which are defined to
return the smallest value >= (or <=) than any of the input parameters.
A different way to look at this is that numbers are not ordered in a
line, but in a lattice. Along the exact and the inexact dimension,
the results are as expected, but when mixing them, we look for the SUP
(INF) in the lattice, so again, the names make sense.
The second rationale is fallacious. Indeed INF (resp. SUP) may return values
not in the set of arguments, but such result is guaranteed to be larger
(resp. smaller) than any of the arguments. The example given fails to have
this property, and renaming MIN and MAX to INF and SUP will not repair the
problem.
The problem is that MIN (or INF) is supposed to return the largest value that
is no smaller than any argument, and currently it fails to do so in Scheme.
So why not just say it that way? Change the definition of MIN and MAX.
Don't give them new names that will have the same problem.
The rationale is not fallacious if you understand that larger or
smaller mean >= and <=, not the expected >= and <= that you compute by
looking at the printed representation. On a good implementation these
two notions of >= should be very close.
If the implementation returns true to the query
(>= 9.999999999999998e99 #e1e100), it is consistent, and is doing what
you expect (modulo it's poor definition of >= or of number->string).
Thanks you for this exposition. (This is what I get for mouthing
off without having been there, I guess. I was reacting only to the
rationales expressed by Will.)
I now shift my position slightly. I agree that a procedure that computes
(??? 1.4 #e1e100) ==> 9.999999999999998e99 may be useful, and that SUP is a
good name for it. I also believe that a procedure is useful that is
defined to return some one of its arguments such that the returned argument
is >= all other arguments, and that MAX is a good name for that procedure.
(One might also argue that, everything else being equal (!), MAX should
return the least-exact argument having that property, but I won't push that.)
Therefore I argue to include all of SUP, INF, MAX, and MIN.
--Guy
∂15-Jul-89 1217 @mc.lcs.mit.edu:chaynes@iuvax.cs.indiana.edu Minutes of the 3rd IEEE Scheme Working Group meeting
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89 12:17:20 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04732;
15 Jul 89 14:18 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jul 89 12:55:16 EDT
Received: from IUVAX.CS.INDIANA.EDU by mintaka.lcs.mit.edu id aa02609;
14 Jul 89 17:28 EDT
Received: by iuvax.cs.indiana.edu
Date: Fri, 14 Jul 89 16:23:53 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu, scheme@mc.lcs.mit.edu,
scheme-standard@wheaties.ai.mit.edu
Subject: Minutes of the 3rd IEEE Scheme Working Group meeting
Message-ID: <8907141728.aa02609@mintaka.lcs.mit.edu>
IEEE/MSC/P1178 Working Group on Scheme
Unapproved Minutes of the Third Meeting
7 July 1989
MIT, Cambridge, MA
SUMMARY
R4RS numbers accepted.
Group believes all major technical issues have been resolved in
preparation for submission of draft.
Next meeting at POPL '90.
ACTIONS
The meeting was called to order by Chris Haynes at about 9:45AM. The
following attendance list was collected:
Hal Abelson MIT
Bill Campbell University of Mass at Boston
William Clinger University of Oregon
Ken Dickey Tektronix
Dan Friedman Indiana University
Dick Gabriel Stanford University
Chris Hanson MIT
Chris Haynes Indiana University
Sidney Marshal Xerox
Tim McNerney ILA
James S. Miller Brandeis University
Eric Ost Indiana University
John D. Ramsdell The MITRE Corporation
Guillerimo J. Rozas MIT
Gerald Jay Sussman MIT
Mitchell Wand Northeastern University
1. The agenda was amended; the changes are reflected by the minutes.
2. John D. Ramsdell was elected secretary.
3. Minutes of the second meeting were accepted with no changes.
4. Differences from the last draft.
Chris Hanson described the changes to the draft introduce since the
last meeting.
Changes agreed on at last meeting:
* "User Interface" appendix removed.
* Restore `substring'.
* Delete `with-input-from-port' and `with-output-to-port'.
Changes from R3.95RS:
* Many small editorial changes.
* Characters added to "extended alphabet" set: + - .
* Added number section (pending outcome of third meeting).
* Added description of "implementation error" in support of numbers section.
* New description of:
number->string
string->number
integer->char
char->integer
peek-char
5. Discuss the number section of the standard.
A long discussion followed, which continued until about 2:00PM (with a
lunch break). This resulted in a much wider understanding and
appreciation of the exact/inexact distinction. (In the process it was
clarified that non-numeric operations on numbers, such as storing and
retrieving them, are not allowed to affect their exactness.)
5.1 Moved and accepted: The editors will change wording in section
1.3.1 to clarify the notion of an implementation error.
Specific directions include, dropping the word "arbitrary" in
paragraph 3 and changing the following two sentences to read something
like: "When an implementation error is reported, the report must make
clear that an implementation restriction was violated. Implementation
restrictions are of course discouraged, but reporting their violation
is encouraged."
5.2 Moved and unanimously accepted: We accept the number section of
R4RS with some editorial changes.
5.3 Moved and accepted: We recommend that the R4RS authors rename the
procedure max to sup, and procedure min to inf.
5.4 Moved and rejected: If R4RS does not change the names of max and
min, P1178 should eliminate max and min.
5.5 Moved and accepted: Add expt to the list of procedures which
must return an exact result when given exact arguments (section 6.5.3).
5.6 Moved and accepted: Add an example showing the use of explicit
coercion of an inexact argument as an index of vector-ref.
5.7 Moved and unanimously accepted: The editors will add to the body
of the text the requirement that implementations must support a
minimal subset of numeric procedures and request that the R4RS authors
change the status to essential of any unessential procedure required
to support the minimal subset.
It was noted that the proscriptive wording (e.g., "shall", "must") in
appendix B.3) should be softened (e.g., "should").
The editors reaffirmed their intention to substantially extend
appendix B.3, including, for instance, a discussion of the
transitivity requirements for the numeric order and equality predicates.
6. R4RS status report
Will Clinger described the changes he expected between R3.95RS and
R4RS. He promised a R3.99RS (R4RS without macro appendices) within a
month.
* Add ... as a <peculiar identifier>.
* Change the branch cuts of some trig functions to be like Common Lisp's.
* Make char->integer and integer->char one-to-one.
* Return char-upper-case? to R4RS, which was dropped due to an editing error.
* Leave it unspecified as to whether the empty list counts as false.
* Change number->string description.
7. Moved and accepted: We request that the R4RS authors add a
sentence encouraging that implementations support an international
character set, most likely ISO Latin 1 (ISO8859-1).
8. A move that ":" be change to not be an extended alphanumeric
character was not seconded.
9. Moved and accepted: We request that the R4RS authors consider
making just list-ref (and not list-tail) essential.
10. A move to discuss changing the semantics of internal definitions was
not seconded.
11. Moved and accepted: It is suggested that the next meeting of the
IEEE Scheme Working Group be on January 19, 1989, following the
Principles of Programming Languages conference in San Francisco, CA.
There was general consensus that at the next meeting the Working Group
could probably approve the draft standard for submission to the MSC
for public comment and balloting. Therefore the draft to be
considered at the next meeting should be mailed to all those on the
Working Group mailing list no later than mid-November.
12. Moved and unanimously accepted: The draft standard distributed at
the meeting (reflecting the changes detailed under item 4 above)
should be submitted to ISO WG-16 for consideration, with a brief
cover statement to be drafted by Chris Haynes.
Dick Gabriel reported that ANSII asked X3J13 whether Scheme and Common
Lisp were distinct enough to justify two standards. Bob Mathis
provided technical arguments convincing ANSII that they were distinct.
Meeting adjourned at about 3:30PM.
-- Minutes by John D. Ramsdell, edited by Chris Haynes
∂15-Jul-89 1323 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu Force & Delay manual reorganization
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89 13:23:04 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05784;
15 Jul 89 15:37 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jul 89 15:03:08 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa04281;
14 Jul 89 19:25 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00232; Fri, 14 Jul 89 19:25:40 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Fri, 14 Jul 89 19:22:40 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA04729; Fri, 14 Jul 89 16:24:54 PDT
Date: Fri, 14 Jul 89 16:24:54 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907142324.AA04729@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Force & Delay manual reorganization
ciao,
Force and delay are currently in totally separate sections of R3.95RS which can
lead readers to hours of fun and enjoyment. Perhaps the Delayed Evaluation
section (4.2.5) can be made a subsection of Control Features (6.9) and expanded
to include force.
(peace chance)
mas
∂15-Jul-89 1328 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu Distinct types for continuations?
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89 13:28:48 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05915;
15 Jul 89 15:49 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jul 89 15:03:27 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa04423;
14 Jul 89 19:40 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00358; Fri, 14 Jul 89 19:40:32 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Fri, 14 Jul 89 19:37:30 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA04796; Fri, 14 Jul 89 16:39:43 PDT
Date: Fri, 14 Jul 89 16:39:43 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907142339.AA04796@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Distinct types for continuations?
ciao,
It seems to us that continuations and procedures should be considered distinct
types. With this in mind we propose the inclusion of a new procedure in R4RS
named continuation? that has the obvious semantics. The procedure procedure?
would, of course, need to be changed such that it would return #f if given a
continuation. This only seems consistent with the decision at L&FP '88 to make
characters and numbers distinct types.
(peace chance)
mas & Morry Katz
∂15-Jul-89 2255 @mc.lcs.mit.edu,@LIFE.ai.mit.edu:shaff@sesame.stanford.edu Arg evaluation order
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89 22:55:26 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12851;
16 Jul 89 0:35 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Jul 89 00:31:28 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12635;
16 Jul 89 0:23 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA10027; Sun, 16 Jul 89 00:23:26 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Sun, 16 Jul 89 00:20:15 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA08066; Sat, 15 Jul 89 11:32:27 PDT
Date: Sat, 15 Jul 89 11:32:27 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907151832.AA08066@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: "Guillermo J. Rozas"'s message of Fri, 14 Jul 89 11:07:53 pdt <8907141808.AA14308@sde.hp.com>
Subject: Arg evaluation order
ciao,
Jinx writes:
1) Not specifying the order of argument evaluation, but requiring
arguments to be evaluated sequentially. Let's call this option
"reordering" of argument evaluation.
2) Allowing interleaving of argument evaluation, ie. evaluate part of
one, then part of another, then part of yet another, then go back to
the first and continue, etc. Let's called this "interleaving" of
argument evaluation.
The current report allows reordering, but not interleaving.
I have not been advocating a change in the semantics that I think most people
agree is intended by the report, rather a clarification (or greater
specificity) in the language regarding this issue.
(peace chance)
mas
∂15-Jul-89 2315 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #160
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89 23:15:44 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13421;
16 Jul 89 1:10 EDT
Date: 16 JUL 89 00:01:54 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #160
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907160110.aa13421@mintaka.lcs.mit.edu>
Scheme Digest #160 16 JUL 89 00:01:54 EDT
Today's Topics:
Opening files with Cscheme
Minutes of the 3rd IEEE Scheme Working Group meeting
----------------------------------------------------------------------
Date: 14 Jul 89 17:53:22 GMT
From: unicads!les@boulder.colorado.edu (Les Milash)
Subject: Re: Opening files with Cscheme
Message-Id: <557@unicads.UUCP>
thanks, everyhody, for telling me about the function `file-exists?'.
you can stop now :-) you've been overwhelmingly helpful.
ya know, i've never gotten more code working faster than with this
wierd Scheme stuff! i guess that's what it's all about, huh?
------------------------------
Date: Fri, 14 Jul 89 16:23:53 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
Subject: Minutes of the 3rd IEEE Scheme Working Group meeting
Message-ID: <8907141728.aa02609@mintaka.lcs.mit.edu>
IEEE/MSC/P1178 Working Group on Scheme
Unapproved Minutes of the Third Meeting
7 July 1989
MIT, Cambridge, MA
SUMMARY
R4RS numbers accepted.
Group believes all major technical issues have been resolved in
preparation for submission of draft.
Next meeting at POPL '90.
ACTIONS
The meeting was called to order by Chris Haynes at about 9:45AM. The
following attendance list was collected:
Hal Abelson MIT
Bill Campbell University of Mass at Boston
William Clinger University of Oregon
Ken Dickey Tektronix
Dan Friedman Indiana University
Dick Gabriel Stanford University
Chris Hanson MIT
Chris Haynes Indiana University
Sidney Marshal Xerox
Tim McNerney ILA
James S. Miller Brandeis University
Eric Ost Indiana University
John D. Ramsdell The MITRE Corporation
Guillerimo J. Rozas MIT
Gerald Jay Sussman MIT
Mitchell Wand Northeastern University
1. The agenda was amended; the changes are reflected by the minutes.
2. John D. Ramsdell was elected secretary.
3. Minutes of the second meeting were accepted with no changes.
4. Differences from the last draft.
Chris Hanson described the changes to the draft introduce since the
last meeting.
Changes agreed on at last meeting:
* "User Interface" appendix removed.
* Restore `substring'.
* Delete `with-input-from-port' and `with-output-to-port'.
Changes from R3.95RS:
* Many small editorial changes.
* Characters added to "extended alphabet" set: + - .
* Added number section (pending outcome of third meeting).
* Added description of "implementation error" in support of numbers section.
* New description of:
number->string
string->number
integer->char
char->integer
peek-char
5. Discuss the number section of the standard.
A long discussion followed, which continued until about 2:00PM (with a
lunch break). This resulted in a much wider understanding and
appreciation of the exact/inexact distinction. (In the process it was
clarified that non-numeric operations on numbers, such as storing and
retrieving them, are not allowed to affect their exactness.)
5.1 Moved and accepted: The editors will change wording in section
1.3.1 to clarify the notion of an implementation error.
Specific directions include, dropping the word "arbitrary" in
paragraph 3 and changing the following two sentences to read something
like: "When an implementation error is reported, the report must make
clear that an implementation restriction was violated. Implementation
restrictions are of course discouraged, but reporting their violation
is encouraged."
5.2 Moved and unanimously accepted: We accept the number section of
R4RS with some editorial changes.
5.3 Moved and accepted: We recommend that the R4RS authors rename the
procedure max to sup, and procedure min to inf.
5.4 Moved and rejected: If R4RS does not change the names of max and
min, P1178 should eliminate max and min.
5.5 Moved and accepted: Add expt to the list of procedures which
must return an exact result when given exact arguments (section 6.5.3).
5.6 Moved and accepted: Add an example showing the use of explicit
coercion of an inexact argument as an index of vector-ref.
5.7 Moved and unanimously accepted: The editors will add to the body
of the text the requirement that implementations must support a
minimal subset of numeric procedures and request that the R4RS authors
change the status to essential of any unessential procedure required
to support the minimal subset.
It was noted that the proscriptive wording (e.g., "shall", "must") in
appendix B.3) should be softened (e.g., "should").
The editors reaffirmed their intention to substantially extend
appendix B.3, including, for instance, a discussion of the
transitivity requirements for the numeric order and equality predicates.
6. R4RS status report
Will Clinger described the changes he expected between R3.95RS and
R4RS. He promised a R3.99RS (R4RS without macro appendices) within a
month.
* Add ... as a <peculiar identifier>.
* Change the branch cuts of some trig functions to be like Common Lisp's.
* Make char->integer and integer->char one-to-one.
* Return char-upper-case? to R4RS, which was dropped due to an editing error.
* Leave it unspecified as to whether the empty list counts as false.
* Change number->string description.
7. Moved and accepted: We request that the R4RS authors add a
sentence encouraging that implementations support an international
character set, most likely ISO Latin 1 (ISO8859-1).
8. A move that ":" be change to not be an extended alphanumeric
character was not seconded.
9. Moved and accepted: We request that the R4RS authors consider
making just list-ref (and not list-tail) essential.
10. A move to discuss changing the semantics of internal definitions was
not seconded.
11. Moved and accepted: It is suggested that the next meeting of the
IEEE Scheme Working Group be on January 19, 1989, following the
Principles of Programming Languages conference in San Francisco, CA.
There was general consensus that at the next meeting the Working Group
could probably approve the draft standard for submission to the MSC
for public comment and balloting. Therefore the draft to be
considered at the next meeting should be mailed to all those on the
Working Group mailing list no later than mid-November.
12. Moved and unanimously accepted: The draft standard distributed at
the meeting (reflecting the changes detailed under item 4 above)
should be submitted to ISO WG-16 for consideration, with a brief
cover statement to be drafted by Chris Haynes.
Dick Gabriel reported that ANSII asked X3J13 whether Scheme and Common
Lisp were distinct enough to justify two standards. Bob Mathis
provided technical arguments convincing ANSII that they were distinct.
Meeting adjourned at about 3:30PM.
-- Minutes by John D. Ramsdell, edited by Chris Haynes
------------------------------
End of Scheme Digest
********************
∂16-Jul-89 1000 @mc.lcs.mit.edu,@decwrl.dec.com:jmiller@crl.dec.com [Scheme-Request@mc.lcs.mit.edu: Scheme Digest #158]
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 16 Jul 89 10:00:17 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00739;
16 Jul 89 11:05 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jul 89 12:55:30 EDT
Received: from decwrl.dec.com by mintaka.lcs.mit.edu id aa02848;
14 Jul 89 17:46 EDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
id AA28239; Fri, 14 Jul 89 09:24:31 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
for rrrs-authors@mc.lcs.mit.edu; id AA28239; Fri, 14 Jul 89 09:24:31 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
id AA05497; Fri, 14 Jul 89 09:42:05 EDT
Date: Fri, 14 Jul 89 09:43:04 EDT
From: jmiller@crl.dec.com
Message-Id: <8907141343.AA02131@peanut.DEC.COM>
To: rrrs-authors@mc.lcs.mit.edu
Subject: [Scheme-Request@mc.lcs.mit.edu: Scheme Digest #158]
Reply-To: JMiller@crl.enet.dec.com
For anyone how hasn't seen it, here's an independent message that
serves to emphasize my argument in favor of Ken Dickey's suggestion
that OPEN-[IN/OUT]PUT-FILE should allow some way of avoiding the
signalled error. The problem is real, not just hypothetical as you
can see from an honest-to-goodness USER of the language.
The message was sent to Scheme@mc.lcs.mit.edu. I editted it for this
transmission.
--Jim
Date: 13 Jul 89 18:36:08 GMT
From: Les Milash <unicads!les@boulder.colorado.edu>
i have a manual called RRRS. i have a problem.
i'm trying to write a program that's c-preprocessor compatable, in that
it takes a -I/parameter -I/that/lists/a/bunch -I/of/directories/that
include files might be in. so when the code includes foo.h i have to
find the first one of
/parameter/foo.h
/that/lists/a/bunch/foo.h
/of/directories/that/foo.h
that exists.
RRRS talks about (open-input-file "filename") but if the file doesn't exist
i get an "out of range with "filename"" error and the program stops.
is there a way to figure out if some file exists without crashing? or
some way to substitute some better error behaviour (i'd just as soon
have it return '() or #!the-you-screwed-up-object or something).
i have the CScheme source and am not adverse to making myself un-scheme-
compatable (but i imagine that scheme can do what i want somehow (else
what good is it?))
∂16-Jul-89 1341 @mc.lcs.mit.edu,@life.ai.mit.edu:danvy@freja.diku.dk Re: Distinct types for continuations?
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 16 Jul 89 13:41:00 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04312;
16 Jul 89 16:29 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Jul 89 16:26:24 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa04243;
16 Jul 89 16:22 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA13763; Sun, 16 Jul 89 16:20:46 EDT
Received: from freja.diku.dk ([129.142.96.1]) by zurich.ai.mit.edu; Sun, 16 Jul 89 16:17:32 edt
Received: by freja.diku.dk
(5.61++/IDA-1.2.8) id AA15278; Sun, 16 Jul 89 17:06:06 +0200
Date: Sun, 16 Jul 89 17:06:06 +0200
From: Olivier Danvy <danvy@diku.dk>
Message-Id: <8907161506.AA15278@freja.diku.dk>
To: rrrs-authors@zurich.ai.mit.edu, shaff@sesame.stanford.edu
Subject: Re: Distinct types for continuations?
A problem in distinguishing procedures and continuations
is the one of eta-redexes.
We would have
(call-with-current-continuation continuation?) -> #t
(call-with-current-continuation procedure?) -> #f
and
(call-with-current-continuation
(lambda (k)
(continuation? k))) -> #t
but
(call-with-current-continuation
(lambda (k)
(continuation? (lambda (v)
(k v))))) -> #f
In other terms, do we want to distinguish k and (lambda (v) (k v))?
Or to introduce some operator "throw" or "continue"?
A motivation for representing first-class continuations as procedures
is that procedures can be defined as continuation transformers:
Cont = Val -> Ans
Proc = Cont -> Val -> Ans = Cont -> Cont
Then it is possible to present first-class continuations
as procedures that substitute the continuations that were reified
for the current continuation.
Peace as well, Olivier
∂16-Jul-89 2144 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #161
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 16 Jul 89 21:44:07 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09261;
17 Jul 89 0:32 EDT
Date: 17 JUL 89 00:01:56 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #161
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907170032.aa09261@mintaka.lcs.mit.edu>
Scheme Digest #161 17 JUL 89 00:01:56 EDT
Today's Topics:
Xscheme object context diffs & sample (425 lines)
The defintion of TRUE and FALSE in Scheme.
----------------------------------------------------------------------
Date: 16 Jul 89 14:12:44 GMT
From: David W Crabb <phoenix!crabb@princeton.edu>
Subject: Xscheme object context diffs & sample (425 lines)
Message-Id: <9447@phoenix.Princeton.EDU>
Since, as far as I know, no solution to the bad behavior of the objects
in Xscheme has yet appeared here, I am posting one.
Two files are appended to this posting:
xschemen.dif
tryit.xs
The former consists of context diffs for the program PATCH . These must be
compiled in order to make the object/class capability of Xscheme, vers. 0.16,
work in a manner similar to Xlisp (especially the versions of Xlisp prior to
the introduction of "send").
The second file is for trying out some of those capabilities, and is
designed to illustrate how close the modification comes to implementing
what was presumably the original design idea.
Note that very few lines of code need to be added or modified:
xscomn.c 1 line added
xsintn.c 3 lines added 1 line deleted
xsobjn.c 8 lines added 4 lines deleted 4 lines modified
---------------- xschemen.dif ----------------------------------------
*** xscom.c Thu Jul 13 14:50:58 1989
--- xscomn.c Thu Jul 13 15:19:04 1989
***************
*** 1,3
/* xscom.c - a simple scheme bytecode compiler */
/* Copyright (c) 1988, by David Michael Betz
All Rights Reserved
--- 1,8 -----
+ /** modified xlfunction
+ David W. Crabb (crabb@phoenix.princeton.edu)
+ July, 1989
+ **/
+
/* xscom.c - a simple scheme bytecode compiler */
/* Copyright (c) 1988, by David Michael Betz
All Rights Reserved
***************
*** 101,107
return (pop());
}
! /* xlfunction - compile a function */
LVAL xlfunction(fun,fargs,body,ctenv)
LVAL fun,fargs,body,ctenv;
{
--- 106,112 -----
return (pop());
}
! /* xlfunction - compile a function */ /* used only by clanswer() **/
LVAL xlfunction(fun,fargs,body,ctenv)
LVAL fun,fargs,body,ctenv;
{
***************
*** 110,115
rplaca(info,newframe(ctenv,1));
rplacd(info,cons(NIL,NIL));
/* setup the base of the code for this function */
cbase = cptr = 0;
--- 115,122 -----
rplaca(info,newframe(ctenv,1));
rplacd(info,cons(NIL,NIL));
+ rplacd (car(info), ctenv); /** DWC: 7/5/89 */
+
/* setup the base of the code for this function */
cbase = cptr = 0;
***************
*** 316,322
/* initialize the argument name list and slot number */
restarg = last = NIL;
slotn = 1;
!
/* handle each required argument */
while (consp(fargs) && (arg = car(fargs)) && !lambdakey(arg)) {
--- 323,329 -----
/* initialize the argument name list and slot number */
restarg = last = NIL;
slotn = 1;
!
/* handle each required argument */
while (consp(fargs) && (arg = car(fargs)) && !lambdakey(arg)) {
*** xsint.c Thu Jul 13 14:50:59 1989
--- xsintn.c Thu Jul 13 14:50:59 1989
***************
*** 1,3
/* xsint.c - xscheme bytecode interpreter */
/* Copyright (c) 1988, by David Michael Betz
All Rights Reserved
--- 1,8 -----
+ /** modified METHOD case of xlapply()
+ David W. Crabb (crabb@phoenix.princeton.edu)
+ July, 1989
+ **/
+
/* xsint.c - xscheme bytecode interpreter */
/* Copyright (c) 1988, by David Michael Betz
All Rights Reserved
***************
*** 6,11
#include "xscheme.h"
#include "xsbcode.h"
/* sample rate (instructions per sample) */
#define SRATE 1000
--- 11,19 -----
#include "xscheme.h"
#include "xsbcode.h"
+ /** from xsobj.c : */
+ #define IVENV 1
+
/* sample rate (instructions per sample) */
#define SRATE 1000
***************
*** 356,362
break;
case METHOD:
xlfun = getcode(xlval);
! xlenv = cons(top(),getenv(xlval));
base = pc = getcodestr(xlfun);
break;
case CONTINUATION:
--- 364,374 -----
break;
case METHOD:
xlfun = getcode(xlval);
!
! xlenv = getenv(xlval); /** DWC 7/5/89 */
! tmp = getivar(top(),IVENV); /** DWC 7/11 */
! rplacd(xlenv, tmp);
!
base = pc = getcodestr(xlfun);
break;
case CONTINUATION:
*** xsobj.c Thu Jul 13 14:50:59 1989
--- xsobjn.c Thu Jul 13 15:10:12 1989
***************
*** 1,3
/* xsobj.c - xscheme object-oriented programming support */
/* Copyright (c) 1988, by David Michael Betz
All Rights Reserved
--- 1,8 -----
+ /** Modifications to clanswer(), clisnew(), and clnew() .
+ David W. Crabb (crabb@phoenix.princeton.edu)
+ July, 1989
+ **/
+
/* xsobj.c - xscheme object-oriented programming support */
/* Copyright (c) 1988, by David Michael Betz
All Rights Reserved
***************
*** 13,18
static LVAL s_self,k_isnew;
static LVAL class,object;
/* instance variable numbers for the class 'Class' */
#define MESSAGES 1 /* list of messages */
#define IVARS 2 /* list of instance variable names */
--- 18,28 -----
static LVAL s_self,k_isnew;
static LVAL class,object;
+ /** DWC: instance variable numbers for objects */
+ #define IVENV 1 /** ivars now passed as an environment */
+ /** number of instance variables for objects */
+ #define IVTOT 2
+
/* instance variable numbers for the class 'Class' */
#define MESSAGES 1 /* list of messages */
#define IVARS 2 /* list of instance variable names */
***************
*** 140,146
/* clnew - create a new object instance */
clnew()
{
! LVAL self;
/* create a new object */
self = xlgaobject();
--- 150,157 -----
/* clnew - create a new object instance */
clnew()
{
! int i;
! LVAL self, ivframe,ivars,c ;
/* create a new object */
self = xlgaobject();
***************
*** 144,150
/* create a new object */
self = xlgaobject();
! xlval = newobject(self,getivcnt(self,IVARTOTAL));
/* send the 'isnew' message */
xlsend(xlval,k_isnew);
--- 155,161 -----
/* create a new object */
self = xlgaobject();
! xlval = newobject(self,IVTOT);
ivars = getivar(self,IVARS);
ivframe = newframe(NIL,listlength(ivars) + 1);
***************
*** 146,151
self = xlgaobject();
xlval = newobject(self,getivcnt(self,IVARTOTAL));
/* send the 'isnew' message */
xlsend(xlval,k_isnew);
}
--- 157,167 -----
self = xlgaobject();
xlval = newobject(self,IVTOT);
+ ivars = getivar(self,IVARS);
+ ivframe = newframe(NIL,listlength(ivars) + 1);
+ setelement(car(ivframe),0,ivars);
+ setivar(xlval,IVENV, ivframe);
+
/* send the 'isnew' message */
xlsend(xlval,k_isnew);
}
***************
*** 153,159
/* clisnew - initialize a new class */
LVAL clisnew()
{
! LVAL self,ivars,cvars,super;
int n;
/* get self, the ivars, cvars and superclass */
--- 169,175 -----
/* clisnew - initialize a new class */
LVAL clisnew()
{
! LVAL self,ivars,cvars,super, tmp;
int n;
/* get self, the ivars, cvars and superclass */
***************
*** 163,172
super = (moreargs() ? xlgaobject() : object);
xllastarg();
- /* create the class variable compile-time environment */
- xlval = cons(xlenter("%%CLASS"),copylists(cvars,NIL));
- cpush(cons(xlval,getivar(super,CVARS)));
-
/* create the class variable environment */
xlval = newvector(listlength(xlval)); setelement(xlval,0,self);
cpush(cons(xlval,getivar(super,CVALS)));
--- 179,184 -----
super = (moreargs() ? xlgaobject() : object);
xllastarg();
/* create the class variable environment */
xlval = newvector(listlength(xlval)); setelement(xlval,0,self);
cpush(cons(xlval,getivar(super,CVALS)));
***************
*** 172,178
cpush(cons(xlval,getivar(super,CVALS)));
/* store the instance and class variable lists and the superclass */
! setivar(self,IVARS,copylists(getivar(super,IVARS),ivars));
setivar(self,CVALS,pop());
setivar(self,CVARS,pop());
setivar(self,SUPERCLASS,super);
--- 184,191 -----
cpush(cons(xlval,getivar(super,CVALS)));
/* store the instance and class variable lists and the superclass */
! setivar(self,IVARS,ivars); /* to be retrieved in clnew() **/
!
setivar(self,CVALS,pop());
tmp = newframe(NIL,listlength(cvars) + 1);
***************
*** 174,180
/* store the instance and class variable lists and the superclass */
setivar(self,IVARS,copylists(getivar(super,IVARS),ivars));
setivar(self,CVALS,pop());
! setivar(self,CVARS,pop());
setivar(self,SUPERCLASS,super);
/* compute the instance variable count */
--- 187,197 -----
setivar(self,IVARS,ivars); /* to be retrieved in clnew() **/
setivar(self,CVALS,pop());
!
! tmp = newframe(NIL,listlength(cvars) + 1);
! setelement(car(tmp),0,cvars);
! setivar(self,CVARS,tmp);
!
setivar(self,SUPERCLASS,super);
/* compute the instance variable count */
***************
*** 191,197
LVAL clanswer()
{
extern LVAL xlfunction();
! LVAL self,msg,fargs,code,mptr;
/* message symbol, formal argument list and code */
self = xlgaobject();
--- 208,214 -----
LVAL clanswer()
{
extern LVAL xlfunction();
! LVAL self,msg,fargs,code,mptr, tmp;
/* message symbol, formal argument list and code */
self = xlgaobject();
***************
*** 206,214
/* add 'self' to the argument list */
cpush(cons(s_self,fargs));
! /* extend the class variable environment with the instance variables */
! xlval = cons(getivar(self,IVARS),getivar(self,CVARS));
!
/* compile and store the method */
xlval = xlfunction(msg,top(),code,xlval);
rplacd(mptr,cvmethod(xlval,getivar(self,CVALS)));
--- 223,230 -----
/* add 'self' to the argument list */
cpush(cons(s_self,fargs));
! tmp = getivar (self,CVARS) ; /** now an env from clisnew() */
!
/* compile and store the method */
xlval = xlfunction(msg,top(),code,tmp);
rplacd(mptr,cvmethod(xlval, tmp));
***************
*** 210,217
xlval = cons(getivar(self,IVARS),getivar(self,CVARS));
/* compile and store the method */
! xlval = xlfunction(msg,top(),code,xlval);
! rplacd(mptr,cvmethod(xlval,getivar(self,CVALS)));
drop(1);
/* return the object */
--- 226,233 -----
tmp = getivar (self,CVARS) ; /** now an env from clisnew() */
/* compile and store the method */
! xlval = xlfunction(msg,top(),code,tmp);
! rplacd(mptr,cvmethod(xlval, tmp));
drop(1);
/* return the object */
----------------------- tryit.xs ------------------------------------
; "tryit.xs" for loading into xscheme - modified version .
; David W. Crabb crabb@phoenix.princeton.edu
(define aClass (Class 'new '(ivar1 ivar2) '(cvar1 cvar2)))
(define anInst (aClass 'new))
(aClass 'answer 'set-cvar1 '(value) '( (set! cvar1 value)))
(aClass 'answer 'cvar1? '() '( (print cvar1)))
(aClass 'show)
(anInst 'set-cvar1 592)
(anInst 'cvar1?) ; >> 592
(aClass 'answer 'set-ivar1 '() '( (set! ivar1 5505)))
(anInst 'set-ivar1)
(aClass 'answer 'ivar1? '() '( (print ivar1)))
(anInst 'ivar1?) ; >> 5505
(define subClass (Class 'new '(ivar1 ivar2) '(cvar1 cvar2) aClass ))
(define subInst (subClass 'new))
(subInst 'cvar1?) ; >> 592
(subInst 'ivar1?) ; >> ()
(aClass 'answer 'reset-ivar1 '() '( (set! ivar1 -66)))
(subInst 'reset-ivar1) (subInst 'ivar1?) ; >> -66
(anInst 'ivar1?) ; >> 5505
;; -------------------- eof ----------------------------------------------
------------------------------
Date: 16 Jul 89 04:18:26 GMT
From: "Mario O. Bourgoin" <mob@media-lab.media.mit.edu>
Subject: The defintion of TRUE and FALSE in Scheme.
Message-Id: <152@mit-amt.MEDIA.MIT.EDU>
I've been wanting to replace the usual LISP definitions of TRUE and
FALSE by functions because that seems more in the spirit of Scheme.
Furthermore, with functions we can eliminate ``if'' and ``cond'' from
the essential syntax of Scheme which simplifies the analysis of
extensions to Scheme such as Zabih, McAllester, and Chapman's
non-deterministic operator, ``amb''. I would like to get the Scheme
community's reaction to the specification of particular objects for
TRUE and FALSE, namely the functions:
(define true (lambda (iftrue iffalse) iftrue))
(define false (lambda (iftrue iffalse) iffalse))
Naturally, the constants #t and #f would always denote the appropriate
one of these two functions.
Given the above definitions for TRUE and FALSE, ``if'' statements can
be replaced according to the following pattern:
(if predicate iftrue iffalse) =>
((predicate (lambda () iftrue) (lambda () iffalse)))
And ``cond'' may be replaced thus:
(cond (predicate1 body1)
(predicate2 body2)
(predicate3 body3)
(else bodyelse))
becomes:
((predicate1
(lambda () body1)
(lambda ()
((predicate2
(lambda () body2)
(lambda ()
((predicate3
(lambda () body3)
(lambda () bodyelse)))))))))
The logical connectives ``not'', ``and'', and ``or'' could be defined
as follows.
(not predicate) => (predicate false true)
(or predicate1 predicate2) => (predicate1 true predicate2)
(and predicate1 predicate2) => (predicate1 predicate2 false)
Naturally, the definitions for ``or'' and ``and'' can be extended to
handle a variable number of parameters.
Please tell me of any problems you see with such a definition.
--Mario O. Bourgoin
------------------------------
End of Scheme Digest
********************
∂17-Jul-89 0910 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com [gls@Think.COM: [postmaster@ames.UUCP: Returned mail: User unknown]]
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89 09:09:59 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16229;
17 Jul 89 12:00 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Jul 89 11:54:51 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa16079;
17 Jul 89 11:49 EDT
Received: from fafnir.think.com by Think.COM; Mon, 17 Jul 89 11:49:22 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 17 Jul 89 11:47:41 EDT
Received: by verdi.think.com; Mon, 17 Jul 89 11:47:39 EDT
Date: Mon, 17 Jul 89 11:47:39 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907171547.AA24575@verdi.think.com>
To: rrrs-authors@mc.lcs.mit.edu, rrrs-authors@life.ai.mit.edu
Subject: [gls@Think.COM: [postmaster@ames.UUCP: Returned mail: User unknown]]
I apologize to those who receive multiple copies of this. The mailers
seem to be a bit confused.
--Guy
Date: Fri, 14 Jul 89 15:56:12 EDT
From: Guy Steele <gls@Think.COM>
To: rrrs-authors@zurich.ai.mit.edu
Subject: [postmaster@ames.UUCP: Returned mail: User unknown]
Date: Fri, 14 Jul 89 12:53:30 -0700
>From: Mail Delivery Subsystem <postmaster@ames.UUCP>
Subject: Returned mail: User unknown
To: gls@think.UUCP
----- Transcript of session follows -----
550 rrrs-authors... User unknown
----- Unsent message follows -----
Received: by ames.arc.nasa.gov (5.61/1.2); Fri, 14 Jul 89 12:53:30 -0700
Received: from verdi.think.com by news.think.com; Fri, 14 Jul 89 15:53:56 EDT
Received: by verdi.think.com; Fri, 14 Jul 89 15:51:27 EDT
Date: Fri, 14 Jul 89 15:51:27 EDT
>From: think!gls (Guy Steele)
Message-Id: <8907141951.AA19139@verdi.think.com>
To: ames!sde.hp.com!hplabs!jinx%hpda
Cc: willc@cs.uoregon.edu, think!gls, ames!rrrs-authors
In-Reply-To: Guillermo J. Rozas's message of Thu, 13 Jul 89 16:04:39 pdt <8907132305.AA01682@hpda.HP.COM>
Subject: Confusion
Date: Thu, 13 Jul 89 16:04:39 pdt
From: Guillermo J. Rozas <hplabs!hpesogg!jinx@ames.UUCP>
I'm confused about a lot of things. Perhaps I should have read Will's
original message more carefully, rather than assume that I knew what
was going on.
P1178 has requested that MIN and MAX be renamed INF and SUP. The rationale
is that the somewhat surprising behavior of MIN and MAX when given mixed
exact and inexact arguments would be more acceptable if their names were
less familiar. A second rationale is that the fact that the mathematical
infimum and supremum operations, when given an infinite set of "arguments",
may return a result that is not in the argument set; this is the surprising
thing about MIN and MAX, e.g. (MAX 1.4 #e1e100) ==> 9.999999999999998e99.
Background: In any case, a note will be added to point out and explain this
behavior, which is required in order for exact results to be trusted. It
happens that MIN and MAX behave this way in Common Lisp as well, although
the motivation was rather different.
As far as I understand it (and GJS agrees with me), the example Will
shows could only be correct in an implementation where
(>= 9.999999999999998e99 #e1e100) is true. If it isn't, the
implementation of MAX/SUP is in error.
If (>= 9.999999999999998e99 #e1e100) holds, then it is not surprising
that MAX/SUP returns 9.999999999999998e99. Perhaps users of such an
implementation should flame at the implementor of >= or of the numeric
printing routine.
The rationale for the renaming these procedures is that MAX and MIN
have a common connotation of returning one of the elements of the
input set. Clearly these procedures don't do this. They are more
like the mathematical definition of SUP and INF which are defined to
return the smallest value >= (or <=) than any of the input parameters.
A different way to look at this is that numbers are not ordered in a
line, but in a lattice. Along the exact and the inexact dimension,
the results are as expected, but when mixing them, we look for the SUP
(INF) in the lattice, so again, the names make sense.
The second rationale is fallacious. Indeed INF (resp. SUP) may return values
not in the set of arguments, but such result is guaranteed to be larger
(resp. smaller) than any of the arguments. The example given fails to have
this property, and renaming MIN and MAX to INF and SUP will not repair the
problem.
The problem is that MIN (or INF) is supposed to return the largest value that
is no smaller than any argument, and currently it fails to do so in Scheme.
So why not just say it that way? Change the definition of MIN and MAX.
Don't give them new names that will have the same problem.
The rationale is not fallacious if you understand that larger or
smaller mean >= and <=, not the expected >= and <= that you compute by
looking at the printed representation. On a good implementation these
two notions of >= should be very close.
If the implementation returns true to the query
(>= 9.999999999999998e99 #e1e100), it is consistent, and is doing what
you expect (modulo it's poor definition of >= or of number->string).
Thanks you for this exposition. (This is what I get for mouthing
off without having been there, I guess. I was reacting only to the
rationales expressed by Will.)
I now shift my position slightly. I agree that a procedure that computes
(??? 1.4 #e1e100) ==> 9.999999999999998e99 may be useful, and that SUP is a
good name for it. I also believe that a procedure is useful that is
defined to return some one of its arguments such that the returned argument
is >= all other arguments, and that MAX is a good name for that procedure.
(One might also argue that, everything else being equal (!), MAX should
return the least-exact argument having that property, but I won't push that.)
Therefore I argue to include all of SUP, INF, MAX, and MIN.
--Guy
∂17-Jul-89 1059 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com [gls@Think.COM: [postmaster@ames.UUCP: Returned mail: User unknown]]
Received: from lcs.mit.edu (XX.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89 10:58:53 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16409;
17 Jul 89 12:09 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Jul 89 11:55:04 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa16080;
17 Jul 89 11:49 EDT
Received: from Think.COM (Gateway.Think.COM) by life.ai.mit.edu (4.1/AI-4.10) id AA00664; Mon, 17 Jul 89 11:49:05 EDT
Received: from fafnir.think.com by Think.COM; Mon, 17 Jul 89 11:49:22 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 17 Jul 89 11:47:41 EDT
Received: by verdi.think.com; Mon, 17 Jul 89 11:47:39 EDT
Date: Mon, 17 Jul 89 11:47:39 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907171547.AA24575@verdi.think.com>
To: rrrs-authors@mc.lcs.mit.edu, rrrs-authors@life.ai.mit.edu
Subject: [gls@Think.COM: [postmaster@ames.UUCP: Returned mail: User unknown]]
I apologize to those who receive multiple copies of this. The mailers
seem to be a bit confused.
--Guy
Date: Fri, 14 Jul 89 15:56:12 EDT
From: Guy Steele <gls@Think.COM>
To: rrrs-authors@zurich.ai.mit.edu
Subject: [postmaster@ames.UUCP: Returned mail: User unknown]
Date: Fri, 14 Jul 89 12:53:30 -0700
>From: Mail Delivery Subsystem <postmaster@ames.UUCP>
Subject: Returned mail: User unknown
To: gls@think.UUCP
----- Transcript of session follows -----
550 rrrs-authors... User unknown
----- Unsent message follows -----
Received: by ames.arc.nasa.gov (5.61/1.2); Fri, 14 Jul 89 12:53:30 -0700
Received: from verdi.think.com by news.think.com; Fri, 14 Jul 89 15:53:56 EDT
Received: by verdi.think.com; Fri, 14 Jul 89 15:51:27 EDT
Date: Fri, 14 Jul 89 15:51:27 EDT
>From: think!gls (Guy Steele)
Message-Id: <8907141951.AA19139@verdi.think.com>
To: ames!sde.hp.com!hplabs!jinx%hpda
Cc: willc@cs.uoregon.edu, think!gls, ames!rrrs-authors
In-Reply-To: Guillermo J. Rozas's message of Thu, 13 Jul 89 16:04:39 pdt <8907132305.AA01682@hpda.HP.COM>
Subject: Confusion
Date: Thu, 13 Jul 89 16:04:39 pdt
From: Guillermo J. Rozas <hplabs!hpesogg!jinx@ames.UUCP>
I'm confused about a lot of things. Perhaps I should have read Will's
original message more carefully, rather than assume that I knew what
was going on.
P1178 has requested that MIN and MAX be renamed INF and SUP. The rationale
is that the somewhat surprising behavior of MIN and MAX when given mixed
exact and inexact arguments would be more acceptable if their names were
less familiar. A second rationale is that the fact that the mathematical
infimum and supremum operations, when given an infinite set of "arguments",
may return a result that is not in the argument set; this is the surprising
thing about MIN and MAX, e.g. (MAX 1.4 #e1e100) ==> 9.999999999999998e99.
Background: In any case, a note will be added to point out and explain this
behavior, which is required in order for exact results to be trusted. It
happens that MIN and MAX behave this way in Common Lisp as well, although
the motivation was rather different.
As far as I understand it (and GJS agrees with me), the example Will
shows could only be correct in an implementation where
(>= 9.999999999999998e99 #e1e100) is true. If it isn't, the
implementation of MAX/SUP is in error.
If (>= 9.999999999999998e99 #e1e100) holds, then it is not surprising
that MAX/SUP returns 9.999999999999998e99. Perhaps users of such an
implementation should flame at the implementor of >= or of the numeric
printing routine.
The rationale for the renaming these procedures is that MAX and MIN
have a common connotation of returning one of the elements of the
input set. Clearly these procedures don't do this. They are more
like the mathematical definition of SUP and INF which are defined to
return the smallest value >= (or <=) than any of the input parameters.
A different way to look at this is that numbers are not ordered in a
line, but in a lattice. Along the exact and the inexact dimension,
the results are as expected, but when mixing them, we look for the SUP
(INF) in the lattice, so again, the names make sense.
The second rationale is fallacious. Indeed INF (resp. SUP) may return values
not in the set of arguments, but such result is guaranteed to be larger
(resp. smaller) than any of the arguments. The example given fails to have
this property, and renaming MIN and MAX to INF and SUP will not repair the
problem.
The problem is that MIN (or INF) is supposed to return the largest value that
is no smaller than any argument, and currently it fails to do so in Scheme.
So why not just say it that way? Change the definition of MIN and MAX.
Don't give them new names that will have the same problem.
The rationale is not fallacious if you understand that larger or
smaller mean >= and <=, not the expected >= and <= that you compute by
looking at the printed representation. On a good implementation these
two notions of >= should be very close.
If the implementation returns true to the query
(>= 9.999999999999998e99 #e1e100), it is consistent, and is doing what
you expect (modulo it's poor definition of >= or of number->string).
Thanks you for this exposition. (This is what I get for mouthing
off without having been there, I guess. I was reacting only to the
rationales expressed by Will.)
I now shift my position slightly. I agree that a procedure that computes
(??? 1.4 #e1e100) ==> 9.999999999999998e99 may be useful, and that SUP is a
good name for it. I also believe that a procedure is useful that is
defined to return some one of its arguments such that the returned argument
is >= all other arguments, and that MAX is a good name for that procedure.
(One might also argue that, everything else being equal (!), MAX should
return the least-exact argument having that property, but I won't push that.)
Therefore I argue to include all of SUP, INF, MAX, and MIN.
--Guy
∂17-Jul-89 1337 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu Distinct types for continuations?
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89 13:37:32 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19418;
17 Jul 89 16:30 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Jul 89 16:27:14 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa19335;
17 Jul 89 16:23 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03828; Mon, 17 Jul 89 16:22:43 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Mon, 17 Jul 89 16:19:29 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA16188; Mon, 17 Jul 89 09:52:43 PDT
Date: Mon, 17 Jul 89 09:52:43 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907171652.AA16188@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Olivier Danvy's message of Sun, 16 Jul 89 17:06:06 +0200 <8907161506.AA15278@freja.diku.dk>
Subject: Distinct types for continuations?
ciao,
According to our reading of Will's denotational semantics for R3.95RS,
continuations and procedures of one argument are in different semantic domains.
This seems to add credence to our desire to be able to distinguish between
continuations and procedures. If it is indeed decided that continuations and
their eta converted versions [e.g., (lambda (v) (k v))] should be
indistinguishable then the denotational semantics should be updated to reflect
this similarity.
(peace chance)
mas & Morry
∂17-Jul-89 1443 @mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Numbers
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89 14:43:40 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20283;
17 Jul 89 17:34 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 17 Jul 89 17:30:20 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 237020; Mon 17-Jul-89 17:29:57 EDT
Date: Mon, 17 Jul 89 17:29 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Subject: Numbers
To: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8907171547.AA24575@verdi.think.com>,
<8907141728.aa02609@mintaka.lcs.mit.edu>,
<8907132208.AA24978@hpda.HP.COM>
Message-ID: <19890717212952.6.ALAN@PIGPEN.AI.MIT.EDU>
Date: Fri, 14 Jul 89 15:51:27 EDT
From: think!gls (Guy Steele)
Subject: Confusion
I now shift my position slightly. I agree that a procedure that computes
(??? 1.4 #e1e100) ==> 9.999999999999998e99 may be useful, and that SUP is a
good name for it. I also believe that a procedure is useful that is
defined to return some one of its arguments such that the returned argument
is >= all other arguments, and that MAX is a good name for that procedure.
(One might also argue that, everything else being equal (!), MAX should
return the least-exact argument having that property, but I won't push that.)
Therefore I argue to include all of SUP, INF, MAX, and MIN.
--Guy
Except MAX and MIN have a bug with respect to the notion of exactness.
They return an exact answer when they are not entitled to. And they have
the good names, so programmers will use them and nobody will use INF and
SUP. Doing this is a subtle way of degrading the concept of an exact
number.
Date: Thu, 13 Jul 89 15:07:27 pdt
From: Gerald Jay Sussman <gjs@hpesogg.hp.com>
You say:
Perhaps a simpler solution to the whole problem is to add a prominent
warning note, like the one attached to `<' and friends, that warns
about the unreliability of `max' and `min' when inexact numbers are in
use.
I agree with your suggestion completely. It is consistent with
everything else we are doing to do it that way. We don't change the
name of "+" to make it less misleading, we warn about the possible
problems and limitations that appear.
Indeed, if we do this, then MIN and MAX are unreliable in the same way that
the numeric predicates are. They will be the only numeric -functions- that
require such a warning. INF and SUP require no such warning.
If we really aren't going to take exactness seriously, then I would rather
not have it at all. If we -are- going to take exactness seriously, then we
should flush "unreliable" MIN and MAX, and change the names of INF and SUP
back to MIN and MAX. INF and SUP are the correct Scheme representation for
the mathematical functions in question, given the principles of exactness.
From the Unapproved Minutes of the Third Meeting of the IEEE Working Group
on Scheme:
5.5 Moved and accepted: Add expt to the list of procedures which
must return an exact result when given exact arguments (section 6.5.3).
Does this mean that (expt 2 50) -must- return an exact number? Suppose I
have an implementation with 32 bit FIXNUMs as my exact numbers, IEEE
FLONUMs as my inexact numbers, but no BIGNUMs. Am I forbidden from
returning a FLONUM (inexact) answer, even though my FLONUMs have the range?
Does this mean that (expt 2 50) would have to signal an error, even though
(* (expt 2 25) (expt 2 25)) would be allowed to return a FLONUM (inexact)
answer?
The editors reaffirmed their intention to substantially extend
appendix B.3, including, for instance, a discussion of the
transitivity requirements for the numeric order and equality predicates.
This should be fun. Once you start letting people take their naive notions
of how numbers should behave and turn them into -requirements-, all hell
can break lose. On what basis do you decide that the order predicates are
required to be transitive, but that + is not required to be associative?
The danger is that requirements may be adopted just in case people can
imagine a way to meet them in an implementation that uses floating point
for its inexact numbers. Unless some restraint is exercised, this can
eliminate plausible implementations of inexact numbers that aren't floating
point.
∂17-Jul-89 1517 @mc.lcs.mit.edu,@life.ai.mit.edu:Alan@REAGAN.ai.mit.edu Distinct types for continuations?
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89 15:17:26 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20669;
17 Jul 89 18:00 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Jul 89 17:56:36 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20499;
17 Jul 89 17:47 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04965; Mon, 17 Jul 89 17:47:02 EDT
Received: from REAGAN.AI.MIT.EDU (reagan.ai.mit.edu) by zurich.ai.mit.edu; Mon, 17 Jul 89 17:43:56 edt
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 237034; Mon 17-Jul-89 17:46:53 EDT
Date: Mon, 17 Jul 89 17:46 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Subject: Distinct types for continuations?
To: shaff@sesame.stanford.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: <8907171652.AA16188@sesame.Stanford.EDU>
Message-Id: <19890717214647.7.ALAN@PIGPEN.AI.MIT.EDU>
Date: Mon, 17 Jul 89 09:52:43 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
According to our reading of Will's denotational semantics for R3.95RS,
continuations and procedures of one argument are in different semantic domains.
This seems to add credence to our desire to be able to distinguish between
continuations and procedures. If it is indeed decided that continuations and
their eta converted versions [e.g., (lambda (v) (k v))] should be
indistinguishable then the denotational semantics should be updated to reflect
this similarity.
Assuming that the denotational semantics hasn't changed drastically since
R3RS, this is false. The objects in the continuation domain are not handed
directly to users, and they would not function correctly if they were. If
you will look at the definition of CALL-WITH-CURRENT-CONTINUATION I think
you will find that it carefully constructs an appropriate object from the
domain of procedures. (Perhaps the name should be changed to
"CALL-WITH-PROCEDURE-CONTAINING-CURRENT-CONTINUATION".) If we decide that
the objects created by CALL-WITH-CURRENT-CONTINUATION -are- distinguishable
from procedures, only then will it be necessary to change the denotational
semantics.
∂17-Jul-89 1533 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu Numbers
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89 15:33:31 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20859;
17 Jul 89 18:12 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Jul 89 18:08:13 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20761;
17 Jul 89 18:05 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA05320; Mon, 17 Jul 89 18:05:26 EDT
Received: from localhost by zurich.ai.mit.edu; Mon, 17 Jul 89 18:02:17 edt
Date: Mon, 17 Jul 89 18:02:17 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907172202.AA10010@zurich.ai.mit.edu>
To: Alan@REAGAN.ai.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden's message of Mon, 17 Jul 89 17:29 EDT <19890717212952.6.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Numbers
Date: Mon, 17 Jul 89 17:29 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
>From the Unapproved Minutes of the Third Meeting of the IEEE Working Group
on Scheme:
5.5 Moved and accepted: Add expt to the list of procedures which
must return an exact result when given exact arguments (section 6.5.3).
Does this mean that (expt 2 50) -must- return an exact number? Suppose I
have an implementation with 32 bit FIXNUMs as my exact numbers, IEEE
FLONUMs as my inexact numbers, but no BIGNUMs. Am I forbidden from
returning a FLONUM (inexact) answer, even though my FLONUMs have the range?
Does this mean that (expt 2 50) would have to signal an error, even though
(* (expt 2 25) (expt 2 25)) would be allowed to return a FLONUM (inexact)
answer?
Whoa, calm down Alan. The list of procedures is prefixed by the
following sentence: "Finally, the procedures listed below will always
return an exact integer result provided all their arguments are exact
integers and the mathematically expected result is representable as an
exact integer within the implementation:". I don't think this should
be cause for alarm, especially since `*' is also in that list.
The editors reaffirmed their intention to substantially extend
appendix B.3, including, for instance, a discussion of the
transitivity requirements for the numeric order and equality predicates.
This should be fun. Once you start letting people take their naive notions
of how numbers should behave and turn them into -requirements-, all hell
can break lose. On what basis do you decide that the order predicates are
required to be transitive, but that + is not required to be associative?
The danger is that requirements may be adopted just in case people can
imagine a way to meet them in an implementation that uses floating point
for its inexact numbers. Unless some restraint is exercised, this can
eliminate plausible implementations of inexact numbers that aren't floating
point.
Am I missing something, or weren't you a party to the discussions at
which it was decided that transitivity was a reasonable requirement?
Looking through my archives I don't see any objections from you and
there is one particular piece of mail which shows you in favor of it.
The reason transitivity is mentioned re appendix B.3 is that we intend
to explain why it is difficult to achieve this correctly, NOT why we
decided to make it a requirement.
In any case the appendix is non-binding so that anything stated there
cannot be a requirement.
∂17-Jul-89 1603 @MC.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89 16:03:07 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21526;
17 Jul 89 18:58 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Jul 89 18:54:27 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa21462;
17 Jul 89 18:50 EDT
Received: from fafnir.think.com by Think.COM; Mon, 17 Jul 89 18:50:37 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 17 Jul 89 18:48:55 EDT
Received: by verdi.think.com; Mon, 17 Jul 89 18:48:53 EDT
Date: Mon, 17 Jul 89 18:48:53 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907172248.AA26384@verdi.think.com>
To: Alan@REAGAN.ai.mit.edu
Cc: gls@think.com, rrrs-authors@MC.lcs.mit.edu
In-Reply-To: Alan Bawden's message of Mon, 17 Jul 89 17:29 EDT <19890717212952.6.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Numbers
Date: Mon, 17 Jul 89 17:29 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Date: Fri, 14 Jul 89 15:51:27 EDT
From: think!gls (Guy Steele)
Subject: Confusion
I now shift my position slightly. I agree that a procedure that computes
(??? 1.4 #e1e100) ==> 9.999999999999998e99 may be useful, and that SUP is a
good name for it. I also believe that a procedure is useful that is
defined to return some one of its arguments such that the returned argument
is >= all other arguments, and that MAX is a good name for that procedure.
(One might also argue that, everything else being equal (!), MAX should
return the least-exact argument having that property, but I won't push that.)
Therefore I argue to include all of SUP, INF, MAX, and MIN.
--Guy
Except MAX and MIN have a bug with respect to the notion of exactness.
They return an exact answer when they are not entitled to. And they have
the good names, so programmers will use them and nobody will use INF and
SUP. Doing this is a subtle way of degrading the concept of an exact
number.
Of course they have the bug. That's the point. There is an inherent
conflict between the notions of "returns the biggest argument" and
"observes functional rules of exactness". So I say give the user his
choice of bugs. I am not impressed by arguments that the users will
necessarily be naive.
...
Indeed, if we do this, then MIN and MAX are unreliable in the same way that
the numeric predicates are. They will be the only numeric -functions- that
require such a warning. INF and SUP require no such warning.
So I happen to regard INF and SUP as "functions" (they really *do* something)
whereas MAX and MIN are just fancy "conditionals" (conditional selectors)
packaged up. Note that CLtL places the descriptions of the Common Lisp MAX
and MIN in the section titled "Comparisons on Numbers", along with =, <, etc.;
they are not in with +, *, etc.
--Guy
∂17-Jul-89 1757 @MC.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Numbers
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89 17:57:43 PDT
Received: by mintaka.lcs.mit.edu id ab22949; 17 Jul 89 20:39 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22897;
17 Jul 89 20:37 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 17 Jul 89 20:26:53 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 237082; Mon 17-Jul-89 20:26:32 EDT
Date: Mon, 17 Jul 89 20:26 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Subject: Numbers
To: gls@think.com
cc: rrrs-authors@MC.lcs.mit.edu
In-Reply-To: <8907172248.AA26384@verdi.think.com>
Message-ID: <19890718002629.0.ALAN@PIGPEN.AI.MIT.EDU>
Date: Mon, 17 Jul 89 18:48:53 EDT
From: gls@Think.COM (Guy Steele)
Date: Mon, 17 Jul 89 17:29 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
...
Except MAX and MIN have a bug with respect to the notion of exactness.
They return an exact answer when they are not entitled to. And they have
the good names, so programmers will use them and nobody will use INF and
SUP. Doing this is a subtle way of degrading the concept of an exact
number.
Of course they have the bug. That's the point. There is an inherent
conflict between the notions of "returns the biggest argument" and
"observes functional rules of exactness". So I say give the user his
choice of bugs.
Then you shouldn't mind if we make MIN and MAX behave the functional way,
and call the ones based on comparison BIGGEST and SMALLEST.
If, whenever someone doesn't like the consequences of the exactness rules,
we introduce a new procedure whose behavior he likes better, giving it the
old name and giving a new name to the old procedure, then ultimately what
good is exactness? In order to reap the benefits of exactness the user has
to write his program using a bunch of unfamiliar names (unfamiliar to
computer weenies) like INF and SUP.
The functions FLOOR, CEILING, TRUNCATE and ROUND are the next candidates
for this treatment. Shall we have two versions of each of them, one that
always returns an exact integer, even given an inexact argument, and
another that properly returns an inexact given an inexact? (Assuming an
implementation in which inexacts are floating point -- if inexacts are
intervals, then FLOOR might really be able to properly return an exact.)
There are certainly people who would prefer the former behavior, even
though the latter is the proper representation of the mathematical
functions.
I'm quite serious when I suggest that if we can't apply the notion of
exactness consistently, then we should abandon it. I would be perfectly
content if Scheme merely had some reasonable rules for floating point
numbers. But if Scheme is going to pretend to do something cleaner and
more general, based on an actual -principle-, then it shouldn't be cowardly
about applying that principle.
I am not impressed by arguments that the users will necessarily be
naive.
I am. It seems to me that the assumption that users will be naive is the
foundation of the art of programming language design. I'm certainly very
naive when I'm writing programs, and I'm grateful for a programming
language that supports me by making the naive choice also the correct
choice as often as possible.
∂17-Jul-89 1905 @mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Numbers
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89 19:05:17 PDT
Received: by mintaka.lcs.mit.edu id aa23907; 17 Jul 89 21:53 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa23823;
17 Jul 89 21:45 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 17 Jul 89 21:08:57 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 237111; Mon 17-Jul-89 21:08:11 EDT
Date: Mon, 17 Jul 89 21:08 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Subject: Numbers
To: cph@ZURICH.ai.mit.edu
cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8907172202.AA10010@zurich.ai.mit.edu>
Message-ID: <19890718010808.1.ALAN@PIGPEN.AI.MIT.EDU>
Date: Mon, 17 Jul 89 18:02:17 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Date: Mon, 17 Jul 89 17:29 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
5.5 Moved and accepted: Add expt to the list of procedures which
must return an exact result when given exact arguments (section 6.5.3).
Does this mean that (expt 2 50) -must- return an exact number?...
Whoa, calm down Alan.
Just what did I say that made you think I had lost my calm? I was just
looking for clarification of what "-must- return an exact result" meant.
The list of procedures is prefixed by the
following sentence: "Finally, the procedures listed below will always
return an exact integer result provided all their arguments are exact
integers and the mathematically expected result is representable as an
exact integer within the implementation:". I don't think this should
be cause for alarm, especially since `*' is also in that list.
Actually, I'd be more interested to know what -isn't- on the list. I'll
bet SQRT isn't there because people think that SQRT of an exact 4 should be
allowed to return something inexact rather than an exact 2. Am I right?
I suspect that if I understood more about this "list" I would argue that
-all- numeric functions belonged on it (including SQRT).
... On what basis do you decide that the order predicates are
required to be transitive, but that + is not required to be
associative?...
Am I missing something, or weren't you a party to the discussions at
which it was decided that transitivity was a reasonable requirement?
Probably.
Looking through my archives I don't see any objections from you and
there is one particular piece of mail which shows you in favor of it.
I don't recall ever strongly advocating it, but I do recall a time when I
through it would be reasonable. I have changed my mind. After accepting
two or three of these requirements on the behavior of inexact numbers (you
will recall that we tried to add requirements so that a portable number
printer was possible), I started to worry that I couldn't see when these
requirements were going to stop accumulating.
The reason transitivity is mentioned re appendix B.3 is that we intend
to explain why it is difficult to achieve this correctly, NOT why we
decided to make it a requirement.
Well, the language that I quoted from the minutes certainly made it sound
like a requirement. (What am I -supposed- to think "transitivity
requirements" means?) I guess that's what makes those minutes unofficial.
∂17-Jul-89 2126 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #162
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89 21:26:15 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25197;
18 Jul 89 0:12 EDT
Date: 18 JUL 89 00:02:01 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #162
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907180012.aa25197@mintaka.lcs.mit.edu>
Scheme Digest #162 18 JUL 89 00:02:01 EDT
Today's Topics:
Question: "Records" in scheme?
----------------------------------------------------------------------
Date: 17 Jul 89 18:03:02 GMT
From: Brian of ASTD-CP <brian@topaz.rutgers.edu>
Subject: Question: "Records" in scheme?
Message-Id: <1455@jato.Jpl.Nasa.Gov>
Is there a way to create contiguous-memory aggregate variables in
scheme? I'd like to be able to read in some arrays of structs
created by a C program (equivalent to arrays of records in Pascal)
into scheme, parse & plot them, and translate parts of them into
scheme lists / vectors. I guess I could print the data out and
read them into scheme data structures, using ASCII as the
communication medium, but they're on the big side (several megs)
and I'd prefer to read them in "binary format" if possible.
------------------------------
End of Scheme Digest
********************
∂18-Jul-89 0833 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 18 Jul 89 08:33:50 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01518;
18 Jul 89 11:28 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Jul 89 11:25:02 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa01452;
18 Jul 89 11:23 EDT
Received: from fafnir.think.com by Think.COM; Tue, 18 Jul 89 11:23:55 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 18 Jul 89 11:22:07 EDT
Received: by verdi.think.com; Tue, 18 Jul 89 11:22:03 EDT
Date: Tue, 18 Jul 89 11:22:03 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907181522.AA29642@verdi.think.com>
To: Alan@REAGAN.ai.mit.edu
Cc: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden's message of Mon, 17 Jul 89 20:26 EDT <19890718002629.0.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Numbers
Date: Mon, 17 Jul 89 20:26 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Date: Mon, 17 Jul 89 18:48:53 EDT
From: gls@Think.COM (Guy Steele)
Date: Mon, 17 Jul 89 17:29 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
...
Except MAX and MIN have a bug with respect to the notion of exactness.
They return an exact answer when they are not entitled to. And they have
the good names, so programmers will use them and nobody will use INF and
SUP. Doing this is a subtle way of degrading the concept of an exact
number.
Of course they have the bug. That's the point. There is an inherent
conflict between the notions of "returns the biggest argument" and
"observes functional rules of exactness". So I say give the user his
choice of bugs.
Then you shouldn't mind if we make MIN and MAX behave the functional way,
and call the ones based on comparison BIGGEST and SMALLEST.
Despite the implied moral obligation to the contrary, in fact I do mind.
"Maximum" *means* "biggest", and "minimum" means "smallest".
However, research into the terminology leads me to another proposal.
"Supremum" and "infimum" refer to height, whereas "maximum" and "minimum"
technically (and literally) refer to *magnitude*:
Adjective superus inferus magnus parvus
Comparative superior inferior major minor
Superlative supremus infimus maximus minimus
[Yes, that really is "parvus", not something reasonable
like "minus". Don't blame me.]
From this I conclude that respect for the original meanings of the
terms would lead us to define SUP and INF to be what everyone else
calls MAX and MIN (ignoring for the moment the treatment of exactness).
We would then define (MAX A B) to be (SUP (ABS A) (ABS B)), and similarly
define MIN as INF of ABS's. But I suppose computer "science" has
already blown that one for us as well, in the same way that people
sloppily refer to a floating-point significand as a "mantissa",
or use "<>" when they mean "/=".
If, whenever someone doesn't like the consequences of the exactness rules,
we introduce a new procedure whose behavior he likes better, giving it the
old name and giving a new name to the old procedure, then ultimately what
good is exactness? In order to reap the benefits of exactness the user has
to write his program using a bunch of unfamiliar names (unfamiliar to
computer weenies) like INF and SUP.
The issue is not reaping the benefits of exactness; it is reaping the
benefits of inexactness. Let us not confuse the two.
As long as we are having fun being polemical (:-), let me also ask this
question: is it the purpose of the rrrs-authors to cater primarily to
computer weenies? (Read: to those corrupted by the accidents of prior
history?)
If the answer is "yes", then let me point out that Scheme weenies are
vastly outnumbered by C weenies, and every C weenie has the formula
#define max(x,y) ((x) > (y)) ? (x) : (y)
engraved in his little weenie brain. See? MAX really is a conditional.
The functions FLOOR, CEILING, TRUNCATE and ROUND are the next candidates
for this treatment. Shall we have two versions of each of them, one that
always returns an exact integer, even given an inexact argument, and
another that properly returns an inexact given an inexact? (Assuming an
implementation in which inexacts are floating point -- if inexacts are
intervals, then FLOOR might really be able to properly return an exact.)
There are certainly people who would prefer the former behavior, even
though the latter is the proper representation of the mathematical
functions.
There is a third possibility: if the inexactness is down at the level that
you can be sure that the integer result is exact (say you know the argument
to within .001 and it is well away from being an integer or half-integer,
as the case may be), then return an exact result; otherwise return an
inexact result (but note that the uncertainty of the result may be
relatively much, much larger than the uncertainty of the input).
I'm quite serious when I suggest that if we can't apply the notion of
exactness consistently, then we should abandon it. I would be perfectly
content if Scheme merely had some reasonable rules for floating point
numbers. But if Scheme is going to pretend to do something cleaner and
more general, based on an actual -principle-, then it shouldn't be cowardly
about applying that principle.
I agree.
I am not impressed by arguments that the users will necessarily be
naive.
I am. It seems to me that the assumption that users will be naive is the
foundation of the art of programming language design. I'm certainly very
naive when I'm writing programs, and I'm grateful for a programming
language that supports me by making the naive choice also the correct
choice as often as possible.
IBM has touted ACRITH as a system that, by using high precision and
interval arithmetic, will save you from all possible ills. See issues of
ACM SIGNUM for descriptions of why it actually loses horribly in many
cases. I suspect that inexactness as currently treated by Scheme is
no panacea.
Gee, Alan, this is fun! Best flame I've had this year.
--Guy
∂18-Jul-89 0901 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu Distinct types for continuations?
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 18 Jul 89 09:01:44 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01826;
18 Jul 89 11:53 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Jul 89 11:48:53 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa01764;
18 Jul 89 11:46 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA14602; Tue, 18 Jul 89 11:45:56 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Tue, 18 Jul 89 11:42:45 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA23868; Tue, 18 Jul 89 08:44:43 PDT
Date: Tue, 18 Jul 89 08:44:43 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907181544.AA23868@sesame.Stanford.EDU>
To: Alan@reagan.ai.mit.edu
Cc: shaff@sesame.stanford.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Alan Bawden's message of Mon, 17 Jul 89 17:46 EDT <19890717214647.7.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Distinct types for continuations?
Date: Mon, 17 Jul 89 17:46 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Date: Mon, 17 Jul 89 09:52:43 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
According to our reading of Will's denotational semantics for R3.95RS,
continuations and procedures of one argument are in different semantic domains.
Assuming that the denotational semantics hasn't changed drastically since
R3RS, this is false. The objects in the continuation domain are not handed
directly to users, and they would not function correctly if they were. If
you will look at the definition of CALL-WITH-CURRENT-CONTINUATION I think
you will find that it carefully constructs an appropriate object from the
domain of procedures.
Now, somewhat bleary eyed from staring at denotational semantics, I have come
to recognize the source of my original misinterpretation and agree with Alan
that the domains of procedures and objects returned from
call-with-current-continuation are the same. Furthermore, I am no longer as
firmly convinced that predicates which distinguish between procedures and
continuations are necessary. However, if we only have a single procedure, I
believe that PROCEDURE? is a serious misnomer. The function should really be
called APPLICABLE?.
(Perhaps the name should be changed to
"CALL-WITH-PROCEDURE-CONTAINING-CURRENT-CONTINUATION".)
Perish the thought. The name is long enough now that almost everyone uses
either CWCC or CALL/CC. I can't even imagine typing CWPCCC.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂18-Jul-89 0925 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu ELSE in Scheme
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 18 Jul 89 09:25:34 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02319;
18 Jul 89 12:20 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Jul 89 12:17:54 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa02092;
18 Jul 89 12:12 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA15011; Tue, 18 Jul 89 12:12:16 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Tue, 18 Jul 89 12:09:06 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA24061; Tue, 18 Jul 89 09:11:25 PDT
Date: Tue, 18 Jul 89 09:11:25 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907181611.AA24061@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Subject: ELSE in Scheme
The following suggestion is intended to be noncontroversial and should be
considered to be self retracting upon the first serious objection.
According to my historian, ELSE was originally introduced into Scheme because
in the old days there was no printable/typable representation for the true
object. This made it impossible to reliably specify an else clause for a COND.
The situation has changed since #t has been introduced in Scheme, and we are no
longer dependent on the tenuous binding of T to the truth object. As a result,
ELSE is no longer really needed as a syntactic keyword. I personally believe
that we should endeavor to minimize the number of keywords in Scheme. I
therefore advocate that we remove ELSE from the list of syntactic keywords and
replace ELSE by #T in the COND examples in RNRS. The dusty deck problem is
solved trivially by including (define ELSE #t) in a compatibility environment.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂18-Jul-89 1014 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu Numbers
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 18 Jul 89 10:13:56 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02825;
18 Jul 89 13:01 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Jul 89 12:57:24 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa02696;
18 Jul 89 12:51 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA15541; Tue, 18 Jul 89 12:51:44 EDT
Received: from localhost by zurich.ai.mit.edu; Tue, 18 Jul 89 12:48:30 edt
Date: Tue, 18 Jul 89 12:48:30 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907181648.AA14360@zurich.ai.mit.edu>
To: Alan@reagan.ai.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden's message of Mon, 17 Jul 89 21:08 EDT <19890718010808.1.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Numbers
Date: Mon, 17 Jul 89 21:08 EDT
From: Alan Bawden <Alan@REAGAN.AI.MIT.EDU>
Date: Mon, 17 Jul 89 18:02:17 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Whoa, calm down Alan.
Just what did I say that made you think I had lost my calm? I was just
looking for clarification of what "-must- return an exact result" meant.
My apologies -- in retrospect there was nothing to indicate this and
my flippant comment was misplaced.
Actually, I'd be more interested to know what -isn't- on the list. I'll
bet SQRT isn't there because people think that SQRT of an exact 4 should be
allowed to return something inexact rather than an exact 2. Am I right?
I suspect that if I understood more about this "list" I would argue that
-all- numeric functions belonged on it (including SQRT).
Correct. I suppose it's a matter of practicality -- nobody wanted to
commit to implement `sqrt' to handle this case specially, presumably
because such behavior isn't too interesting. To take it further, I
suppose it wouldn't hurt to add the transcendental functions to the
list, since there should be no case where exact integer arguments
produce a mathematical result which is an integer (I'm guessing on
this -- but I suspect it's true).
Here is a list of those number-valued procedures that do not appear in
the list:
/ sqrt
exp log sin cos tan asin acos atan make-polar angle
make-rectangular real-part imag-part magnitude
exact->inexact inexact->exact
The only good reason why `/' and `sqrt' should not be in the list is
efficiency and implementation complexity. Maybe that's not good
enough.
I suspect that there's no argument for keeping the transcendental
functions out of the list since my intuition tells me that there is no
case where integer arguments provide an integer result; if there is
such a case, it's probably pretty obscure, and perhaps that would be a
good reason to exclude them from the list. A similar argument holds
for `make-polar' and `angle'.
For the procedures in the third line above, I see no reason not to
include them in the list as well. Finally, `exact->inexact' clearly
cannot be in the list, while `inexact->exact' should have been
included in the first place.
Summary: the only procedures that seem to matter are `/' and `sqrt',
and the argument in favor of excluding them is pragmatic.
Am I missing something, or weren't you a party to the discussions at
which it was decided that transitivity was a reasonable requirement?
Probably.
Looking through my archives I don't see any objections from you and
there is one particular piece of mail which shows you in favor of it.
I don't recall ever strongly advocating it, but I do recall a time when I
through it would be reasonable. I have changed my mind. After accepting
two or three of these requirements on the behavior of inexact numbers (you
will recall that we tried to add requirements so that a portable number
printer was possible), I started to worry that I couldn't see when these
requirements were going to stop accumulating.
I remember those discussions. I believe that most of the requirements
were eliminated in the final draft, but the transitivity requirement
was not. I believe the reason for the transitivity requirement was to
eliminate the N-squared behavior on the number of arguments, which
seems like a pretty good reason to me.
The reason transitivity is mentioned re appendix B.3 is that we intend
to explain why it is difficult to achieve this correctly, NOT why we
decided to make it a requirement.
Well, the language that I quoted from the minutes certainly made it sound
like a requirement. (What am I -supposed- to think "transitivity
requirements" means?) I guess that's what makes those minutes unofficial.
There is an explicit transitivity requirement in the R4RS numbers
section, which was placed there after earlier discussions of which you
were a part. The IEEE Standard picked up this requirement along with
the rest of the numbers section. However, the decision reached at the
meeting was to expand the appendix to explain the consequences of this
requirement. Perhaps the minutes should be edited to make this
clearer.
∂18-Jul-89 1206 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 18 Jul 89 12:06:46 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04500;
18 Jul 89 15:01 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Jul 89 14:56:41 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa04376;
18 Jul 89 14:52 EDT
Received: from fafnir.think.com by Think.COM; Tue, 18 Jul 89 14:52:45 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 18 Jul 89 14:51:02 EDT
Received: by verdi.think.com; Tue, 18 Jul 89 14:51:00 EDT
Date: Tue, 18 Jul 89 14:51:00 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907181851.AA02935@verdi.think.com>
To: cph@zurich.ai.mit.edu
Cc: Alan@REAGAN.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Chris Hanson's message of Tue, 18 Jul 89 12:48:30 edt <8907181648.AA14360@zurich.ai.mit.edu>
Subject: Numbers
Date: Tue, 18 Jul 89 12:48:30 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
... I
suppose it wouldn't hurt to add the transcendental functions to the
list, since there should be no case where exact integer arguments
produce a mathematical result which is an integer (I'm guessing on
this -- but I suspect it's true).
0
e = cos 0 = 1. But you are right if you say there are *very*
few such exceptions.
∂18-Jul-89 1528 cph@zurich.ai.mit.edu test message
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 18 Jul 89 15:28:27 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA19538; Tue, 18 Jul 89 18:01:58 EDT
Received: from localhost by zurich.ai.mit.edu; Tue, 18 Jul 89 17:58:54 edt
Date: Tue, 18 Jul 89 17:58:54 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8907182158.AA16987@zurich.ai.mit.edu>
To: rrrs-authors@ai.mit.edu
Subject: test message
This is a test, please ignore.
∂18-Jul-89 2204 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #163
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 18 Jul 89 22:04:29 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA23793; Wed, 19 Jul 89 00:20:26 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09750;
19 Jul 89 0:05 EDT
Date: 19 JUL 89 00:01:59 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #163
To: Scheme@mc.lcs.mit.edu
Reply-To: Scheme@mc.lcs.mit.edu
Message-Id: <8907190005.aa09750@mintaka.lcs.mit.edu>
Scheme Digest #163 19 JUL 89 00:01:59 EDT
Today's Topics:
scheme for unix systems
test message
----------------------------------------------------------------------
Date: 18 Jul 89 20:06:55 GMT
From: gwusun!bleen.gwu.edu!stoler@uunet.uu.net
Subject: scheme for unix systems
Message-Id: <1418@bleen.gwusun.gwu.edu>
We are in the process of installing an HP 9000/835se and need to know of
an implementation of scheme that runs on said machine.
We also need to know of implementations that run on a SUN 3/180 and
similar machines.
Public domain implementations that can be ftp'd would be nice but commercial
products are okay too.
Thanks all.
------------------------------
Date: Tue, 18 Jul 89 18:06:27 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907182206.AA16993@zurich.ai.mit.edu>
Subject: test message
This is a test message, please ignore.
------------------------------
End of Scheme Digest
********************
∂19-Jul-89 2155 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #164
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 19 Jul 89 21:55:37 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA12182; Thu, 20 Jul 89 00:20:05 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24709;
20 Jul 89 0:03 EDT
Date: 20 JUL 89 00:02:08 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #164
To: Scheme@mc.lcs.mit.edu
Reply-To: Scheme@mc.lcs.mit.edu
Message-Id: <8907200003.aa24709@mintaka.lcs.mit.edu>
Scheme Digest #164 20 JUL 89 00:02:08 EDT
Today's Topics:
Scheme for unix systems
----------------------------------------------------------------------
From: Duke Briscoe <briscoe-duke@YALE.EDU>
Message-Id: <8907191538.AA13269@ELI.CS.YALE.EDU>
Date: Wed, 19 Jul 89 11:41:23 EDT
Subject: re: Scheme for unix systems
The T language has a Scheme environment which is about 99% compatible
with the Scheme standard, based on my recent experience porting
several thousand lines of Scheme code to the T system. The quality of
the T compiler is very good, producing code which is comparable in
speed to Pascal and C. It also adds some useful extensions to Scheme,
including multiple return values, a simple object system, debugger and
inspector, macros, structures, hash tables. It is available for
VAXes, Sun 3, Apollo, HPs, and both parallel and sequential versions
for Encore Multimax. According to the information I have from Lisp
Pointers Vol. 1, #6, it is available by FTP from some sites at MIT,
but I just tried there, and I couldn't find it. Maybe someone else
can give the latest info on how to get it.
-------
------------------------------
End of Scheme Digest
********************
∂20-Jul-89 1457 @mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:ziggy@hx.lcs.mit.edu BYTES (a.k.a. 1's and 0's)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Jul 89 14:57:04 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA22327; Thu, 20 Jul 89 17:38:52 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06187;
20 Jul 89 17:33 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 20 Jul 89 17:33:54 EDT
Received: from HX.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 276082; 20 Jul 89 17:33:48 EDT
Received: by hx.LCS.MIT.EDU (5.51/4.7); Thu, 20 Jul 89 17:33:11 EDT
Message-Id: <2825962373-3531500@RTS-8>
Sender: ziggy@rts-8.lcs.mit.edu
Date: Thu, 20 Jul 89 17:32:53 EDT
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
To: rrrs-authors@zermatt.lcs.mit.edu
Subject: BYTES (a.k.a. 1's and 0's)
I am building a simulator for a computer CPU, which is much like building an
interpreter for a language. My problem is that the processor instruction set I
want to simulate includes instructions like LOGICAL-AND, SHIFT-LEFT, ROTATE,
SIGN-EXTEND and such like, for 2's complement numbers.
My problem is that I *know* that the underlying processor my Scheme is running
on has these instructions but my portable Revised↑3 implementation of Scheme
does not give me access to these underlying instructions (precisely because they
are not in the Revised↑3 manual).
It seems a *real* inconvenience to implement these (say) as procedures over
lists/vectors of booleans and I don't cherish the thought of MOD/QUOT-ing till
I'm blue in the face. And it's a shame knowing these features are just out of
reach, buried behind an abstraction barrier between my CPU and Scheme.
Has there ever been a proposal to add this stuff to the Report?
If so, what were the compelling reasons for it's rejection?
Does anyone have a Revised↑3 portable implementation of this stuff I can use
in the meantime?
Doesn't Bombin' LISP (oh, sorry... Common LISP) provide such a facility?
Should I be using a non-toy language like C instead? (;-)!!!!!!!)
Cheers,
~Ziggy
∂20-Jul-89 1631 @mc.lcs.mit.edu,@life.ai.mit.edu:jar@sid.stanford.edu Bitwise logical operations
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Jul 89 16:31:18 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA23471; Thu, 20 Jul 89 19:12:36 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07222;
20 Jul 89 19:08 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Jul 89 19:08:19 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07202;
20 Jul 89 19:04 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA23338; Thu, 20 Jul 89 19:04:18 EDT
Received: from mojave.Stanford.EDU (mojave.stanford.edu) by zurich.ai.mit.edu; Thu, 20 Jul 89 19:01:07 edt
Received: from Edusa.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
id AA23454; Thu, 20 Jul 89 16:01:31 PDT
Message-Id: <8907202301.AA23454@mojave.Stanford.EDU>
Received: by sid; Thu, 20 Jul 89 16:03:52 pdt
Date: Thu, 20 Jul 89 16:03:52 pdt
To: ziggy@hx.lcs.mit.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: "Michael R. Blair"'s message of Thu, 20 Jul 89 17:32:53 EDT <2825962373-3531500@RTS-8>
Subject: Bitwise logical operations
From: Jonathan Rees <jar%sid.stanford.edu@polya.stanford.edu>
Sender: jar@sid.stanford.edu
Come on now, you can define everything you need in Revised↑3 Scheme!
(define (lognot i)
(- -1 i))
(define (logand x y)
(cond ((= x 0) 0)
((= x -1) y)
(else
(+ (ash (logand (ash x -1) (ash y -1)) 1)
(if (and (odd? x) (odd? y)) 1 0)))))
(define (logior x y)
(lognot (logand (lognot x) (lognot y))))
(define (logxor x y)
(logand (lognot (logand x y)) (logior x y)))
(define (ash n m)
(define (ash-nonnegative n m)
(if (> m 0)
(* n (expt 2 m))
(quotient n (expt 2 (- m)))))
(cond ((or (= m 0) (= n 0)) n)
((> n 0) (ash-nonnegative n m))
((> m 0)
(- (ash-nonnegative (- n) m)))
(else
(lognot (ash-nonnegative (lognot n) m)))))
Seriously, however, I agree with you. I think Scheme should include
two's-complement bitwise logical operations that work on integers.
I'd suggest adding to the report something similar to a subset of what
Common Lisp provides. How about:
(logand i1 ...)
(logior i1 ...)
(logxor i1 ...)
(lognot i)
(ash i1 i2)
(integer-length i)
with the same meanings as in Common Lisp (assuming I remember the
Common Lisp names properly). Of course they have to be insensitive to
word length.
Load bit field and deposit bit field are also pretty useful, but I
wouldn't advocate inventing a byte specifier pseudo-type like CL does.
Nor would I approve of CL's argument order, which I find impossible to
remember.
Logical shift and rotate don't make sense unless a word size is
supplied. They can be synthesized pretty easily given the other
operations, so I'd say don't include them.
∂21-Jul-89 0124 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: last call: changes for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 01:23:54 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA28369; Fri, 21 Jul 89 04:11:21 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12217;
21 Jul 89 2:42 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 02:42:32 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12174;
21 Jul 89 2:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27578; Fri, 21 Jul 89 02:38:11 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 02:35:07 edt
Received: from Semillon.ms by ArpaGateway.ms ; 20 JUL 89 10:33:29 PDT
Date: Thu, 20 Jul 89 10:34:19 PDT
From: Pavel.pa@xerox.com
Subject: Re: last call: changes for R4RS
In-Reply-To: <8907130003.AA17137@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890720-103329-118@Xerox>
I'd rather that we did not cut off debate on R4RS at the end of this month.
It seems to me that there are several reasonably important issues currently
on the table that could make it into R4RS in the very near future (e.g.,
uniform definition semantics, fluid binding, and regularization of
procedures). I would hate to see R4RS come out so little changed from the
previous report; in a sense, what's the point?
I do, however, understand the desire of the IEEE group to have a solid
commitment from the authors very soon. They might be satisfied, though,
with a promise that the set of valid R4RS programs will be a superset of
the valid R3.99RS programs. None of the proposals I mentioned above
violate this promise (the only non-trivial case is uniform definition
semantics; the liberalized semantics supported by John Ramsdell and me does
not change the meaning of any valid R3.95RS program). In this way, the
IEEE group can proceed with the assurance that they will publish a
conservative subset of R4RS without requiring that report to be finalized
immediately.
Pavel
∂21-Jul-89 0125 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: last call: changes for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 01:24:59 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA28375; Fri, 21 Jul 89 04:14:15 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12219;
21 Jul 89 2:42 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 02:42:41 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12176;
21 Jul 89 2:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27581; Fri, 21 Jul 89 02:38:25 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 02:35:16 edt
Received: from Semillon.ms by ArpaGateway.ms ; 20 JUL 89 10:58:57 PDT
Date: Thu, 20 Jul 89 10:59:23 PDT
From: Pavel.pa@xerox.com
Subject: Re: last call: changes for R4RS
In-Reply-To: <8907130003.AA17137@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890720-105857-125@Xerox>
Controversial changes requiring positive action by the authors if they
are
to be adopted in the R4RS:
Section 6.3.
P1178 has requested again that LIST-REF be made essential, for
parallelism
with VECTOR-REF and STRING-REF. Their previous request that LIST-TAIL
be
made essential has been dropped.
I support this, strongly if the other non-controversial regularization
proposals are also accepted, and more weakly otherwise.
Section 6.5.5.
P1178 has requested that MIN and MAX be renamed INF and SUP. The
rationale
is that the somewhat surprising behavior of MIN and MAX when given
mixed
exact and inexact arguments would be more acceptable if their names
were
less familiar. A second rationale is that the fact that the
mathematical
infimum and supremum operations, when given an infinite set of
"arguments",
may return a result that is not in the argument set; this is the
surprising
thing about MIN and MAX, e.g. (MAX 1.4 #e1e100) ==>
9.999999999999998e99.
Background: In any case, a note will be added to point out and explain
this
behavior, which is required in order for exact results to be trusted.
It
happens that MIN and MAX behave this way in Common Lisp as well,
although
the motivation was rather different.
I believe that I agree with GLS on this one. I do not see MAX as an
operation that computes a result in the same sense as addition. Rather, it
is a convenient packaging of a common use of the <= function. It seems to
me inconsistent that MAX should behave differently than the obvious
rewriting in terms of <=. Once <= establishes a total order on the numbers
in any given implementation, MAX should perform the simple operation
implied by its name; that is, it should return the largest element in the
set of its arguments. Just as <= does not return an ``inexact'' boolean,
MAX should not be affected by the exactness of its arguments.
I would have no problem with a repetition under MAX of the warning under <=
about comparing inexact numbers, so long as MAX is defined to return one of
its arguments. If others have a great use for INF and SUP (by which I mean
what some are describing as the current semantics for MIN and MAX) then I
suppose I won't stand in the way; however, I feel strongly about the proper
meaning of MIN and MAX.
Noncontroversial changes that will be adopted in the R4RS unless the
authors
object:
...
Section 6.2.
EQV?-ness is preserved when storing into and fetching from the standard
data structures (pairs, vectors, strings). [Note: EQ?-ness isn't
necessarily preserved. Preservation of EQV?-ness implies preservation
of exactness, which is the context in which P1178 requested this
change.]
I would be unhappy with any statement that distinguished between the
behavior of, for example, the car cell of a pair and the contents of a
lexical variable; EQ?-ness should not be guaranteed for one but not the
other. Thus, I support this change only if it is extended to include
variables. Pragmatically, the storage for a variable is just as likely to
be type-specialized as that for a pair or vector.
Pavel
∂21-Jul-89 0342 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: legion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 03:42:19 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA29094; Fri, 21 Jul 89 06:30:36 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12221;
21 Jul 89 2:43 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 02:42:50 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12178;
21 Jul 89 2:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27582; Fri, 21 Jul 89 02:38:26 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 02:35:22 edt
Received: from Semillon.ms by ArpaGateway.ms ; 20 JUL 89 11:10:44 PDT
Date: Thu, 20 Jul 89 11:11:17 PDT
From: Pavel.pa@xerox.com
Subject: Re: legion
In-Reply-To: <8907130005.AA17154@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890720-111044-128@Xerox>
Date: Wed, 12 Jul 89 17:05:39 PDT
From: will@cs.uoregon.edu
If indeed we must add fluid variables to the language, then I think that
we should do something very like Pavel's proposal. I'm not keen on
adding fluid variables, however. If we are to add any dynamic features
I'd rather add DYNAMIC-WIND, which seems simpler and more useful. If
we had DYNAMIC-WIND and a macro package, then people could pull their
favorite semantics for fluid variables out of the yellow pages.
Unfortunately, DYNAMIC-WIND is not enough. There appears to be a great
deal of confusion between the capabilities offered by DYNAMIC-WIND and
fluid binding; the two are completely orthogonal in general. In
particular, on a shared-memory multiprocessor (I feel like a broken
record...), DYNAMIC-WIND cannot be used to implement fluid binding. It can
only be used for shallow-binding implementations and, as I've described
twice already, shallow-binding cannot work correctly on a shared-memory
multiprocessor.
I would support an additional proposal to add DYNAMIC-WIND to the language,
but cannot support it to the exclusion of fluid binding. If we are to
avoid discrimination against multiprocessor implementations like Scheme
Xerox, fluid binding must be a part of the language, not a yellow pages
package.
Will:
2. (This reason is pretty weak.) For the compiler writer, I
think the freedom to rearrange definitions makes closure
analysis a little simpler when procedure definitions are
mixed with definitions of variables containing non-procedure
values.
This is incorrect. The compiler would still have the freedom to move
procedure definitions in front of other definitions, since it could
make a difference only if the program is in error. Once the procedure
definitions have been grouped together, their order makes no difference
under either semantics.
Given your retraction of this objection and John's and my unanswered
refutations of your first one, may we assume that you now support the
proposal to unify definition semantics? If not, could you say more?
Pavel
∂21-Jul-89 0346 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: Regularization of list, vector, and string procedures
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 03:46:16 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA29100; Fri, 21 Jul 89 06:32:22 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12223;
21 Jul 89 2:43 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 02:42:58 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12180;
21 Jul 89 2:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27587; Fri, 21 Jul 89 02:38:31 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 02:35:26 edt
Received: from Semillon.ms by ArpaGateway.ms ; 20 JUL 89 11:40:06 PDT
Date: Thu, 20 Jul 89 11:32:07 PDT
From: Pavel.pa@xerox.com
Subject: Re: Regularization of list, vector, and string procedures
In-Reply-To: <8907130007.AA17164@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890720-114006-139@Xerox>
Morry suggested adding a procedure named ``list?'' to test for a
null-terminated list. Will approved, but preferred the name
``proper-list?''.
I thought this as well (the function is called ``proper-list?'' in Cedar
Scheme) and almost said so in my response to Morry. First, however, I
looked up the definition of lists in R3RS. In contrast to CLtL, which
explicitly allows ``list'' to refer both to ``true lists''
(null-terminated) and ``dotted lists'', R3RS is fairly strict on the point.
It says,
``A chain of pairs not ending in the empty list is called
an IMPROPER LIST. Note that an improper list is not a list.''
I thus concluded that ``proper-list?'' was a redundant name and that
``list?'' was more appropriate. I don't feel very strongly about this,
though.
Will also says:
I'd prefer to avoid generic procedures at the lowest levels of Scheme.
Why not have LIST-APPLY, VECTOR-APPLY, and STRING-APPLY, by analogy with
LIST-LENGTH, VECTOR-LENGTH, and STRING-LENGTH etc?
Assuming that ``apply'' is initially bound to the same value as
``list-apply'', I don't object to this proposal. It will be amusing to see
if I ever find a use for either of ``vector-apply'' or ``string-apply''.
Finally, Will made a proposal for higher-order functions ``make-map'' and
``make-for-each'' to provide for generalized mapping functionality. I have
two objections to the proposal:
-- Since ``make-map'' takes a ``ref'' procedure for each aggregate
argument, it takes quadratic time to map down lists and other linked
structures. While it might be the case, as Will states, that make-map
``could be made equally efficient for the cases that could be handled by
generic MAP'' (though I don't see how, in general), this inefficiency could
not be overcome for other, user-defined linked structures. Thus, the
proposal is not as generally applicable as it might initially seem.
-- Such a facility crosses my threshold for the amount of experimentation
appropriate in the report. To my knowledge, no implementation has any
experience with such a facility. Thus, I would rather leave ``map'' and
``for-each'' as unsolved problems in R4RS and have Will or someone else
contribute an implementation of ``make-map'' and ``make-for-each'' to the
library. Then we could all play around with them for a while before
committing them to the report.
Pavel
∂21-Jul-89 0453 ramsdell@linus.mitre.org Priorities
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 04:52:59 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA29624; Fri, 21 Jul 89 07:33:00 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA28604; Fri, 21 Jul 89 07:29:25 EDT
Posted-Date: Fri, 21 Jul 89 07:29:03 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA06493; Fri, 21 Jul 89 07:29:04 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8907211129.AA06493@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Priorities
Date: Fri, 21 Jul 89 07:29:03 EDT
I am worried that the important issues are being lost in this debate.
Let me give you my ranking of the issues.
(1) Issues from Snowbird.
[A] Macros: I had hoped to see some form of syntactic closures in
R4RS. I have heard there is no acceptable implementation
of extend-syntax using syntactic closures yet. It appears we
must find an alternative to the Snowbird macro compromise.
[B] Regularization of Procedure Names: This is being discussed as
it should be.
(2) Post Snowbird issues.
[A] Uniform Definition Semantics: Adding macros to Scheme may
affect this proposal.
[B] Fluid Binding: Didn't Pavel say something about how this issue
should be easy?
(3) Post R4RS issues.
[A] Multiple Value Return: We nearly had agreement, I suspect we
could reach agreement in time for R5RS.
[B] Modules: There are no proposals on the table, but keep thinking!
I do not want to imply that the other issues being debated are not
worth discussing. For example, I support the addition of bitwise
logical operators. I just hope the above list of issues does not get
lost.
John
∂21-Jul-89 0553 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: ELSE in Scheme
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 05:53:50 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00377; Fri, 21 Jul 89 08:39:42 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12227;
21 Jul 89 2:43 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 02:43:13 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12184;
21 Jul 89 2:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27591; Fri, 21 Jul 89 02:38:39 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 02:35:35 edt
Received: from Semillon.ms by ArpaGateway.ms ; 20 JUL 89 20:07:57 PDT
Date: Thu, 20 Jul 89 12:05:04 PDT
From: Pavel.pa@xerox.com
Subject: Re: ELSE in Scheme
In-Reply-To: <8907181611.AA24061@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890720-200757-1264@Xerox>
I would rather see ELSE remain in the language. The old LISP idiom of
using T as the predicate in the final COND-clause always struck me as a
hack that sort of ``happens'' to work. In my mind ELSE is more abstract
and thus easier to read. I remember, as a Common Lisp programmer, first
reading about Scheme and being pleased with ELSE's presence. I always used
OTHERWISE at the end of my Common Lisp CASE expressions, too.
Pavel
∂21-Jul-89 0807 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: Fluid binding
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 08:07:22 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01820; Fri, 21 Jul 89 10:45:47 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12225;
21 Jul 89 2:43 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 02:43:07 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12182;
21 Jul 89 2:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27590; Fri, 21 Jul 89 02:38:36 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 02:35:30 edt
Received: from Semillon.ms by ArpaGateway.ms ; 20 JUL 89 20:07:15 PDT
Date: Thu, 20 Jul 89 12:01:25 PDT
From: Pavel.pa@xerox.com
Subject: Re: Fluid binding
In-Reply-To: <8907130921.AA28558@hpda.HP.COM>
To: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890720-200715-1255@Xerox>
Date: Thu, 13 Jul 89 02:20:39 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
I think calling these objects fluid "variables" in the context of
other Scheme variables is very misleading. Lexical (ordinary) Scheme
variables can't be aliased, since their addresses cannot be passed
around. These can. Lexical variables can only be affected by special
forms, these can be affected (and usually are) by procedures. Lexical
variables are not first class, they are not even objects since they
are not expressible values. Yours are first class objects. It seems
to me that these fluid variables are much more similar to pairs than
to anything else in the language.
Let's put it another way. In the absence of FLUID-LET, what is the
difference between your fluids and 1-slot records? Your
interpretation is that there is a lot of hair in fluid environments,
etc. Mine is simpler: there are cells, and there is a special form
which establishes a temporary/isolated contents for them. Except for
efficiency, there is no reason why that could not be generalized to
pairs, vectors, etc.
Fascinating; your perspective is completely opposite to mine. You ask,
``In the absence of FLUID-LET, what is the difference between your fluids
and 1-slot records?'' The answer, clearly, is ``nothing''. But FLUID-LET
is the whole issue, isn't it? You perceive my interpretation in terms of a
fluid environment as ``a lot of hair'', but it seems to me this idea os
``temporary/isolated contents'' is considerably hairier. In particular,
FLUID-LET in your interpretation is a side-effect that must carefully be
un-done or re-done whenever control leaves or re-enters the body of the
form. This seems very messy to me, conceptually; I shudder to think how it
would look when added to the formal semantics. A fluid environment, on the
other hand, is another instance of a well-understood concept. It is
essentially trivial to add it to the formal semantics, and under that
conception, FLUID-LET is no more a side-effect than LET.
Perhaps we can avoid having to convince one another on this issue, however.
If you could agree to leave the names MAKE-FLUID, FLUID-REF, FLUID-SET!,
FLUID-LET, and WITH-FLUID-BINDING, I would certainly have no problem with
describing both conceptions in the informal definition in the report.
This brings up the issue of using the name FLUID-LET even though it
currently has different meanings in certain implementations. I suggested
renaming the current forms to make way for the new meaning. Jinx replied:
Your solution assumes that you can reach all code that used FLUID-LET.
That is unlikely in a wide-spread implementation.
But surely a wide-spread implementation has some social mechanism by which
the changes in the supported language are communicated to the users. Let
your release notes mention prominently that the name of the form has
changed. The fix to user code is easy for each user to apply.
A second objection is purely based on the name. I don't think that
FLUID-LET is a very appropriate name for your form, since it is (in my
mind, where all you are doing is data structure manipulation)
unrelated to LET. I'd much rather have your form be called ISOLATE,
TEMPORARILY, or something like that.
As noted above, I disagree strongly with this conception of what's going on
in these forms. Can we find some middle ground that lets both of us retain
our models?
Hopefully,
Pavel
∂21-Jul-89 0812 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com last call: changes for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 08:11:28 PDT
Received: from Score.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB01839; Fri, 21 Jul 89 10:48:18 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa14471;
21 Jul 89 6:08 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 06:07:53 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa14438;
21 Jul 89 6:00 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA28950; Fri, 21 Jul 89 06:00:10 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 05:57:06 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA09171; Fri, 21 Jul 89 02:59:50 pdt
Message-Id: <8907210959.AA09171@sde.hp.com>
Received: by hpesogg; Fri, 21 Jul 89 02:58:57 pdt
Date: Fri, 21 Jul 89 02:58:57 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 20 Jul 89 10:59:23 PDT <890720-105857-125@Xerox>
Subject: last call: changes for R4RS
Reply-To: jinx%hpesogg@sde.hp.com
I believe that I agree with GLS on this one. I do not see MAX as an
operation that computes a result in the same sense as addition. Rather, it
is a convenient packaging of a common use of the <= function. It seems to
me inconsistent that MAX should behave differently than the obvious
rewriting in terms of <=. Once <= establishes a total order on the numbers
in any given implementation, MAX should perform the simple operation
implied by its name; that is, it should return the largest element in the
set of its arguments. Just as <= does not return an ``inexact'' boolean,
MAX should not be affected by the exactness of its arguments.
I don't understand people's desire for MAX/SUP and MIN/INF to return a
result EQV? to one of the inputs.
Perhaps there is still confusion about the issues, so let's consider
the consequences in a typical implementation (all inexact reals are
represented as floating point, exact integers have unlimited range):
- max/sup is given a set of exact reals. The result will be an exact
real both = and eqv? to one of the inputs. No surprises here.
- max/sup is given a set of inexact numbers. The result will be an
inexact number both = and eqv? to one of the inputs. No surprises here.
- max/sup is given a mixture of exact numbers and inexact numbers:
The first observation is that the fact that the result is inexact
should cause no problems in code, since after all, the inputs were of
mixed exactness and thus the "largest input" might easily have been
inexact. In particular doing (vector-ref v (max ...)) where the
arguments to max are of mixed exactness is clearly foolish. Thus the
only problem is the fact that the result may not be eqv? or even = to
one of the inputs.
The possibilities are as follows:
1) The "largest" input happens to be inexact. No surprises here.
2) The "largest" input is exact, and its value can be represented as
an inexact number without any loss of precision. The result will be =
to one of the inputs, although not eqv?
3) The "largest" input is exact, but its value is too large be
represented as an inexact number. It seems to me that under these
circumstances a good implementation should signal an implementation
error because of an out of range coercion.
4) The "largest" input is exact, but its value cannot be represented
as an inexact number without loss of precision (the bignum has more
significant bits than the length of the mantissa in the floating point
representation). A good implementation would coerce to floating point
rounding towards infinity (ie. add 1 at the least significant mantissa
bit after truncating the bits) in order to return a value >= than all
the inputs.
Thus the "surprises" arise from cases 2, 3, and 4 above.
I think that cases 3 and 4 are rare, since mixed bignum/inexact
computation is not common (in my experience). The level of surprise
here is pretty low. Case 3 in particular would probably be less
surprising, although more annoying. Note also that cases 3 and 4 can
be "fixed" if the implementation includes an exactness bit for
bignums, since the result would then be = to one of the inputs.
Case 2 is the only really surprising case. This arises from max/sup'ing
2 and 1.5, for example. How surprising is it really? The result is =
to the largest input, and depending on eqv? of the result is at best
obscure, so the only surprise would come in output, where the inexact
value would have a decimal digit and the exact would not.
Is this really so worrisome to everyone? It seems to me that the
people worried about the surprise factor are worrying too much about
exactly one case, namely what their interactive system will print when
they call max/sup or min/inf from top level, but that is not very
interesting, or worth worrying much about.
PS:
(define (max/sup a b)
(/ (+ (+ a b) (abs (- a b)))
2))
[Modulo overflow or roundoff]
Inexact contagion implies that the result should be inexact if either
input is inexact.
∂21-Jul-89 1019 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com legion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 10:19:25 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA03373; Fri, 21 Jul 89 12:54:40 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa15136;
21 Jul 89 7:44 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 07:44:31 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa15117;
21 Jul 89 7:40 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA29723; Fri, 21 Jul 89 07:40:12 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 07:37:08 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA10355; Fri, 21 Jul 89 04:39:56 pdt
Message-Id: <8907211139.AA10355@sde.hp.com>
Received: by hpesogg; Fri, 21 Jul 89 04:39:05 pdt
Date: Fri, 21 Jul 89 04:39:05 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 20 Jul 89 11:11:17 PDT <890720-111044-128@Xerox>
Subject: legion
Reply-To: jinx%hpesogg@sde.hp.com
Unfortunately, DYNAMIC-WIND is not enough. There appears to be a great
deal of confusion between the capabilities offered by DYNAMIC-WIND and
fluid binding; the two are completely orthogonal in general. In
particular, on a shared-memory multiprocessor (I feel like a broken
record...), DYNAMIC-WIND cannot be used to implement fluid binding. It can
only be used for shallow-binding implementations and, as I've described
twice already, shallow-binding cannot work correctly on a shared-memory
multiprocessor.
I agree that dynamic-wind is not enough, but it is not independent of
fluid-binding. The multiprocessor implementation of fluid binding can
still be based on dynamic-wind:
(fluid-let ((<cell> <value>))
<code>)
expands into
(with-new-fluid-value <cell> <value> (lambda () <code>))
with
(define (with-new-fluid-value fluid-cell new-value thunk)
(with-fluid-bindings-list
(cons (cons fluid-cell new-value)
(get-fluid-bindings-list))
thunk))
(define (with-fluid-bindings-list inside)
(let ((outside (get-fluid-bindings-list)))
(dynamic-wind
(lambda ()
(set-fluid-bindings-list! inside))
thunk
(lambda ()
(set-fluid-bindings-list! outside)))))
(define (user-cwcc receiver)
(with-fluid-bindings-list
(get-fluid-bindings-list)
(lambda ()
(primitive-cwcc-that-knows-about-dynamic-wind
receiver))))
Where set/get-fluids-bindings-list operate on the process/processor state.
Dynamic-wind still offers the correct isolation between the region
with the new binding and the region with the original binding. The
difference is how the entry and exit thunks swap bindings.
∂21-Jul-89 1220 cph@zurich.ai.mit.edu test
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 12:20:36 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA04573; Fri, 21 Jul 89 14:29:07 EDT
Received: from localhost by zurich.ai.mit.edu; Fri, 21 Jul 89 14:26:04 edt
Date: Fri, 21 Jul 89 14:26:04 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8907211826.AA04776@zurich.ai.mit.edu>
To: scheme-inbox@ai.mit.edu
Subject: test
Another test message, please ignore.
∂21-Jul-89 1449 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Regularization of list, vector, and string procedures
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 14:49:11 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA06938; Fri, 21 Jul 89 17:27:35 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa15291;
21 Jul 89 8:04 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 08:04:41 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa15232;
21 Jul 89 7:57 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA29809; Fri, 21 Jul 89 07:56:58 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 07:53:42 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA10576; Fri, 21 Jul 89 04:56:29 pdt
Message-Id: <8907211156.AA10576@sde.hp.com>
Received: by hpesogg; Fri, 21 Jul 89 04:55:30 pdt
Date: Fri, 21 Jul 89 04:55:30 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 20 Jul 89 11:32:07 PDT <890720-114006-139@Xerox>
Subject: Regularization of list, vector, and string procedures
Reply-To: jinx%hpesogg@sde.hp.com
I thought this as well (the function is called ``proper-list?'' in Cedar
Scheme) and almost said so in my response to Morry. First, however, I
looked up the definition of lists in R3RS. In contrast to CLtL, which
explicitly allows ``list'' to refer both to ``true lists''
(null-terminated) and ``dotted lists'', R3RS is fairly strict on the point.
It says,
``A chain of pairs not ending in the empty list is called
an IMPROPER LIST. Note that an improper list is not a list.''
I thus concluded that ``proper-list?'' was a redundant name and that
``list?'' was more appropriate. I don't feel very strongly about this,
though.
I feel relatively strongly about it. At the original r2rs meeting I
suggested calling it list? since I had always felt that the concept of
a "proper list" was funny. I don't remember whether it made it into
r2rs and was then flushed, or what happened, but I would not like it
to be called proper-list?.
I'd prefer to avoid generic procedures at the lowest levels of Scheme.
Why not have LIST-APPLY, VECTOR-APPLY, and STRING-APPLY, by analogy with
LIST-LENGTH, VECTOR-LENGTH, and STRING-LENGTH etc?
Assuming that ``apply'' is initially bound to the same value as
``list-apply'', I don't object to this proposal. It will be amusing to see
if I ever find a use for either of ``vector-apply'' or ``string-apply''.
I don't see a point to STRING-APPLY or VECTOR-APPLY (except to be used
with STRING or VECTOR to copy a string or vector). I think we should
leave APPLY alone for the following reasons:
- Apply is not really an operation on lists. It is a hook into the
procedure calling mechanism of the language so that procedures with
arbitrary arity can be called with arbitrary numbers of arguments.
Applying to lists is traditional, although funny in the same way that
arbitrary arity procedures (procedures with dotted lambda lists) build
lists.
The right way to fix APPLY is not to generalize it along its spurious
direction, but to devise some way by which we can drop user data
structures altogether from this hook into the system, for example, by
designing an alternative based on procedures.
- The kind of manipulation where apply is used is more conveniently
done on lists than on any other data structures. It is also natural
to think of argument lists as lists, rather than vectors or strings.
I agree that MAP and FOR-EACH should be left alone for the time
being.
∂21-Jul-89 1642 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com last call: changes for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 16:41:48 PDT
Received: from MINTAKA.LCS.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB08183; Fri, 21 Jul 89 19:28:15 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17889;
21 Jul 89 12:25 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 12:24:51 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa17868;
21 Jul 89 12:22 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02981; Fri, 21 Jul 89 12:22:33 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Fri, 21 Jul 89 12:19:18 edt
Received: from fafnir.think.com by Think.COM; Fri, 21 Jul 89 12:20:52 EDT
Received: from verdi.think.com by fafnir.think.com; Fri, 21 Jul 89 12:18:59 EDT
Received: by verdi.think.com; Fri, 21 Jul 89 12:18:56 EDT
Date: Fri, 21 Jul 89 12:18:56 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907211618.AA19787@verdi.think.com>
To: jinx%hpesogg@sde.hp.com
Cc: Pavel.pa@xerox.com, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: "Guillermo J. Rozas"'s message of Fri, 21 Jul 89 02:58:57 pdt <8907210959.AA09171@sde.hp.com>
Subject: last call: changes for R4RS
Date: Fri, 21 Jul 89 02:58:57 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
...
Case 2 is the only really surprising case. This arises from max/sup'ing
2 and 1.5, for example. How surprising is it really? The result is =
to the largest input, and depending on eqv? of the result is at best
obscure, so the only surprise would come in output, where the inexact
value would have a decimal digit and the exact would not.
Is this really so worrisome to everyone? It seems to me that the
people worried about the surprise factor are worrying too much about
exactly one case, namely what their interactive system will print when
they call max/sup or min/inf from top level, but that is not very
interesting, or worth worrying much about.
Well, I think it is worth worrying about.
PS:
(define (max/sup a b)
(/ (+ (+ a b) (abs (- a b)))
2))
[Modulo overflow or roundoff]
Actually, I had considered including this very definition in my initial
message as a joke. But it muddies the issue. Completely aside from
questions of overflow, I think this is not the model of MAX that most
programmers carry around in their heads.
Inexact contagion implies that the result should be inexact if either
input is inexact.
(1) I see no reason why the rules of inexact contagion should
apply to MAX. As Pavel has observed, >= does not return an
inexact boolean. (If >= were to be three-valued (yes/no/maybe)
then it would be more consistent.)
(2) The requirement of contagion is particularly onerous in the
case where it results in an implementation producing a range error
when simply returning the exact argument would have been fine.
(N.B. With IEEE 754 floating-point arithmetic there is at least
an explicit representation of infinity. Maybe non-754 floating-point
should be declared broken and therefore forbidden by the Scheme standard.)
--Guy
∂21-Jul-89 1649 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu ELSE in Scheme
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 16:49:01 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA08328; Fri, 21 Jul 89 19:35:44 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17991;
21 Jul 89 12:37 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 12:37:09 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa17966;
21 Jul 89 12:34 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02730; Fri, 21 Jul 89 12:05:01 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Fri, 21 Jul 89 12:01:51 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA09018; Fri, 21 Jul 89 09:03:59 PDT
Date: Fri, 21 Jul 89 09:03:59 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907211603.AA09018@sesame.Stanford.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 20 Jul 89 12:05:04 PDT <890720-200757-1264@Xerox>
Subject: ELSE in Scheme
Date: Thu, 20 Jul 89 12:05:04 PDT
From: Pavel.pa@xerox.com
I would rather see ELSE remain in the language. The old LISP idiom of
using T as the predicate in the final COND-clause always struck me as a
hack that sort of ``happens'' to work. In my mind ELSE is more abstract
and thus easier to read. I remember, as a Common Lisp programmer, first
reading about Scheme and being pleased with ELSE's presence. I always used
OTHERWISE at the end of my Common Lisp CASE expressions, too.
Pavel
My proposal does not prevent you from using else within CONDs in your programs.
As stated in my original message, all you have to do is put the definition
(define else #t) in your program. Furthermore, if you prefer the term
OTHERWISE you could use this instead and include the definition
(define otherwise #t) in your programs. All I wanted was to remove ELSE from
the list of syntactic keywords so that other people, myself included, can use
the identifier ELSE for other purposes if we so choose.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂21-Jul-89 1854 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu last call: changes for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 18:53:57 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA09344; Fri, 21 Jul 89 21:39:56 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19581;
21 Jul 89 14:45 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 14:45:19 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa19451;
21 Jul 89 14:41 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA04753; Fri, 21 Jul 89 14:41:08 EDT
Received: from localhost by zurich.ai.mit.edu; Fri, 21 Jul 89 14:38:05 edt
Date: Fri, 21 Jul 89 14:38:05 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907211838.AA04787@zurich.ai.mit.edu>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 20 Jul 89 10:59:23 PDT <890720-105857-125@Xerox>
Subject: last call: changes for R4RS
Date: Thu, 20 Jul 89 10:59:23 PDT
From: Pavel.pa@xerox.com
Noncontroversial changes that will be adopted in the R4RS unless the
authors object:
...
Section 6.2.
EQV?-ness is preserved when storing into and fetching from the standard
data structures (pairs, vectors, strings). [Note: EQ?-ness isn't
necessarily preserved. Preservation of EQV?-ness implies preservation
of exactness, which is the context in which P1178 requested this
change.]
I would be unhappy with any statement that distinguished between the
behavior of, for example, the car cell of a pair and the contents of a
lexical variable; EQ?-ness should not be guaranteed for one but not the
other. Thus, I support this change only if it is extended to include
variables. Pragmatically, the storage for a variable is just as likely to
be type-specialized as that for a pair or vector.
I agree, though I would go slightly further, if the wording can be
worked out: since we have a definition of the "store" in the report,
can we say that EQV?-ness is preserved when storing and fetching from
these locations? If worded correctly I think that can capture the
essence of what we need to say here.
∂21-Jul-89 1856 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: Bitwise logical operations
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 18:56:48 PDT
Received: from MINTAKA.LCS.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB09360; Fri, 21 Jul 89 21:41:14 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19173;
21 Jul 89 14:15 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 14:15:00 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa19144;
21 Jul 89 14:10 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04362; Fri, 21 Jul 89 14:10:45 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 14:07:40 edt
Received: from Semillon.ms by ArpaGateway.ms ; 21 JUL 89 10:45:20 PDT
Date: Fri, 21 Jul 89 10:47:14 PDT
From: Pavel.pa@xerox.com
Subject: Re: Bitwise logical operations
In-Reply-To: <8907202301.AA23454@mojave.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890721-104520-3334@Xerox>
I strongly support Jonathan's bitwise logical operations proposal. I've
missed having these more than once.
Pavel
∂21-Jul-89 2101 @mc.lcs.mit.edu,@life.ai.mit.edu:jmiller@crl.dec.com Regularization of list, vector, and string procedures
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 21:01:22 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA10197; Fri, 21 Jul 89 23:47:21 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20822;
21 Jul 89 16:33 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 16:16:16 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20419;
21 Jul 89 16:10 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA05746; Fri, 21 Jul 89 16:09:43 EDT
Received: from decwrl.dec.com ([16.1.0.1]) by zurich.ai.mit.edu; Fri, 21 Jul 89 16:06:27 edt
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
id AA12047; Fri, 21 Jul 89 07:08:04 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
for rrrs-authors@zurich.ai.mit.edu; id AA12047; Fri, 21 Jul 89 07:08:04 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
id AA13877; Fri, 21 Jul 89 09:38:41 EDT
Date: Fri, 21 Jul 89 09:30:45 EDT
From: jmiller@crl.dec.com
Message-Id: <8907211330.AA00412@peanut.DEC.COM>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@zurich.ai.mit.edu, Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: 20-Jul-89 1132 PDT's message of Fri, 21 Jul 89 06:47:31 EDT <8907211047.AA13726@crl.crl.dec.com>
Subject: Regularization of list, vector, and string procedures
Reply-To: JMiller@crl.enet.dec.com
COMMENTS PRIMARILY TO THE RRRS-AUTHORS LIST
I prefer to remain relatively silent on this mailing list, and send
mail only when it is something I feel strongly about, or is something
that I feel I should handle wearing my IEEE co-editor hat. (Someone
asked why there wasn't more comment on the content of the list; that's
my justification.)
As co-editor of the IEEE draft standard, I'd like to mention a
discussion that occurred earlier this week among the editors:
For virtually every data type mentioned in a procedure header line in
R4RS there is either an existing predicate in the language (string?
for string, vector? for vector, rational? for q_{n}, etc.) or a
trivial piece of code (like (lambda (k) (and (integer? k) (exact? k)
(positive? k))) for k_{n}). Not so for (proper) lists referred to as
"list" in the header line. It was our intention to have P1178 make
this connection explicit, whether or not R4RS chooses to do so, and
the missing predicate for proper lists causes a problem.
We had not planned to ask RNRS to change to add such a test. But
someone else has, so I'd like to support the addition of the predicate
LIST? that tests for proper lists. I don't mind if you call it
PROPER-LIST?, but I prefer the other name, especially since the
language of the report is very clear about the definition of a list,
and it excludes both cdr-circularity and dotted tails. Another
predicate might be of interest to RnRS (NOT-TAIL-CIRCULAR? or some
such) but you won't hear me agitating to have that added to the IEEE
proposal.
On another point, but still wearing my co-editor hat: I can't agree
with Pavel about keeping R4RS open. Let's simply take John Ramsdell's
list and agree that the Snowbird issues constitute R4RS (that's what
the meeting was for, anyway) and start NOW on R5RS issues, too: those
in John's Post Snowbird and (I don't like the name) Post R4RS list.
Let's aim for R5RS in about one year or so, and try to keep the
language alive by agreeing on changes and issuing reports frequently.
COMMENT TO BOTH RRRS-AUTHORS and SCHEME-STANDARD LISTS
Finally, as co-editor, I'd like to poll both mailing lists about one
of the many items that appeared in the GLS/Alan/cph mail about
numbers. Guy did a wonderful job restating my qualms (expressed at
the last IEEE meeting) about max/min. His observation explains my
objection to Will's assertion that their omission from the version of
Scheme used in his class last year was a trivial issue. There are
two, equally reasonable (in my opinion), interpretations of the MAX
and MIN operations.
(a) They are selectors from a set of numbers and thus there is
a legitimate expectation that (memq (max <set>) <set>) ==>
#t. (Yes, I DO mean memq not memv.)
(b) MAX and MIN are well-defined mathematical operations on a
set of numbers and hence the "contagious inexactness" rule
applies. In this case, (memv (max <set>) <set>) need not
be true due to implementation restrictions that make it
impossible to represent the (inexact) result with
sufficient accuracy for the result to be = to the (exact)
element from which it was derived.
Using the former concept, our definition of the Scheme functions would
need to be modified, but the argument in favor of the name change to
SUP/INF is inappropriate. Using the latter concept, there is an
argument that SUP/INF are superior names for what is actually
happening (based on the observation that SUP and INF of a set may
return limit elements that are not members of the set).
Can I have an informal show of hands? Please vote:
(1) Keep the names MAX and MIN, and make the semantics be
selector-like.
(2) Change the names to SUP and INF, and leave the semantics.
(3) Provide all 4 names and both semantics.
(4) Other.
If your answer depends on whether you are voting on a change to
R3.95RS or to P1178, please indicate.
--Jim Miller
P.S. -- In writing the above, I discovered a question I should be able
to answer but can't. First, notice that (max <set>) under
interpretation (b) (the current one) may signal an error even when all
elements of the set are real numbers -- due to the same implementation
restrictions. Question: are there real numbers that cause errors when
compared using < and so forth? I can't quite tell from reading
R3.95RS or P1178. Perhaps it is related to the requirement for
transitivity?
∂21-Jul-89 2104 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Fluid binding
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 21:03:54 PDT
Received: from gang-of-four.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB10203; Fri, 21 Jul 89 23:50:32 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22110;
21 Jul 89 18:23 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 18:23:18 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa22103;
21 Jul 89 18:21 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07629; Fri, 21 Jul 89 18:21:07 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 18:18:00 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA22658; Fri, 21 Jul 89 15:20:44 pdt
Message-Id: <8907212220.AA22658@sde.hp.com>
Received: by hpesogg; Fri, 21 Jul 89 13:58:04 pdt
Date: Fri, 21 Jul 89 13:58:04 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 20 Jul 89 12:01:25 PDT <890720-200715-1255@Xerox>
Subject: Fluid binding
Reply-To: jinx%hpesogg@sde.hp.com
Fascinating; your perspective is completely opposite to mine. You ask,
``In the absence of FLUID-LET, what is the difference between your fluids
and 1-slot records?'' The answer, clearly, is ``nothing''. But FLUID-LET
is the whole issue, isn't it? You perceive my interpretation in terms of a
fluid environment as ``a lot of hair'', but it seems to me this idea os
``temporary/isolated contents'' is considerably hairier. In particular,
FLUID-LET in your interpretation is a side-effect that must carefully be
un-done or re-done whenever control leaves or re-enters the body of the
form. This seems very messy to me, conceptually; I shudder to think how it
would look when added to the formal semantics. A fluid environment, on the
other hand, is another instance of a well-understood concept. It is
essentially trivial to add it to the formal semantics, and under that
conception, FLUID-LET is no more a side-effect than LET.
Your argument is like saying that COND is "bad" because it is hard to
implement in the semantics. I don't care about writing directly in
the semantics when the construct can be provided conveniently by user
code.
Your model conceptually needs modification of the formal semantics,
while mine can be implemented trivially in a page of code. Which is
simpler?
I don't believe in cluttering up the semantics when the same
functionality can be provided as efficiently by user code.
∂21-Jul-89 2316 @mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 23:16:32 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA12005; Sat, 22 Jul 89 02:07:57 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21114;
21 Jul 89 16:57 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 21 Jul 89 16:57:46 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 239123; Fri 21-Jul-89 16:57:26 EDT
Date: Fri, 21 Jul 89 16:57 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Subject: Numbers
To: gls@think.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8907181522.AA29642@verdi.think.com>
Message-Id: <19890721205725.0.ALAN@PIGPEN.AI.MIT.EDU>
Date: Tue, 18 Jul 89 11:22:03 EDT
From: gls@Think.COM (Guy Steele)
If, whenever someone doesn't like the consequences of the exactness rules,
we introduce a new procedure whose behavior he likes better, giving it the
old name and giving a new name to the old procedure, then ultimately what
good is exactness? In order to reap the benefits of exactness the user has
to write his program using a bunch of unfamiliar names (unfamiliar to
computer weenies) like INF and SUP.
The issue is not reaping the benefits of exactness; it is reaping the
benefits of inexactness. Let us not confuse the two.
Well actually, I expect that the tension between the benefits of exactness
and the benefits of inexactness is the root of most disagreements about
(in)exactness. The benefits of exactness are error checking. When I write
(vector-ref v (/ (* n (+ 1 n)) 2))
I know that, independent of the characteristics of arithmetic in my Scheme
implementation, I will be referencing the same element of the vector as
long as VECTOR-REF doesn't signal an error. If the multiplication
overflows the range of exact integers in some implementation and returns an
inexact, then the division will return an inexact as well, and then
VECTOR-REF will signal an error. Of course I give up this benefit of
exactness whenever I call a numeric predicate (and the manual takes pains
to warn me about this). The proposal is to abandon this benefit for MAX
and MIN as well.
(If I was being a real purist trouble maker, I would propose that the
predicates should behave just like VECTOR-REF, and signal an error when
given an inexact argument; then I would propose a parallel family of
"inexact numeric predicates" (PROBABLY-<, PROBABLY-=, PROBABLY-INTEGER?,
PROBABLY-ODD?, etc.) that would compare both exact and inexact numbers.)
The benefits of inexactness are that certain numerical questions can be
answered that would be very difficult to answer otherwise. (Although it
sometimes takes a numerical analyst to demonstrate that the answer really
is -correct-.) I don't see that the benefits of inexactness are enhanced
(or degraded) by making MIN and MIX unsafe.
..., then let me point out that Scheme weenies are vastly outnumbered
by C weenies, and every C weenie has the formula
#define max(x,y) ((x) > (y)) ? (x) : (y)
engraved in his little weenie brain. See? MAX really is a conditional.
Sure is. So much of a conditional that it even evaluates the expression
that returns the larger result -twice-! So I guess to a C weenie, MAX is
more like IF than +.
[About FLOOR, etc.:]
... if the inexactness is down at the level that you can be sure that
the integer result is exact (say you know the argument to within .001
and it is well away from being an integer or half-integer, as the case
may be), then return an exact result; otherwise return an inexact
result (but note that the uncertainty of the result may be relatively
much, much larger than the uncertainty of the input).
Right. Of course in the usual floating point implementation of inexact
numbers, the precision isn't represented explicitly (it exists only in the
mind of the numerical analyst who wrote the program), so FLOOR can't do
this. But certainly for other kinds of inexact implementations, such as
intervals or continued fractions, having FLOOR perform this kind of
analysis is perfectly reasonable, and does allow you to sometimes return an
exact result given inexact arguments.
... It seems to me that the assumption that users will be naive is
the foundation of the art of programming language design....
IBM has touted ACRITH as a system that, by using high precision and
interval arithmetic, will save you from all possible ills. See issues of
ACM SIGNUM for descriptions of why it actually loses horribly in many
cases. I suspect that inexactness as currently treated by Scheme is
no panacea.
Yeah, every time I mention interval arithmetic as an alternate
implementation for inexact numbers, someone volunteers to educate me about
what a lose intervals can be. Fortunately, I don't care how bad they can
be. I'm only interested in them as a "model" of something that obeys the
"axioms" of inexact numbers that -isn't- floating point.
But I don't see what the merits of interval arithmetic has to do with my
position on programmer naivete. I wasn't proposing interval arithmetic as
something that can help naive programmers. I was suggesting that
programmers will naively choose a function named "MIN" instead of a
function named "INF" in situations where they don't see that it can
possibly make any difference. And I claim that in situations where you
don't think it makes any difference, you probably want the function that
properly propogates inexactness.
Quick, without thinking hard, decide whether would you write
A. (vector-ref v (min max-index (/ (* n (+ 1 n)) 2)))
or
B. (vector-ref v (inf max-index (/ (* n (+ 1 n)) 2))) ?
I'll bet that most people would answer A. After all, MIN is the familiar
sounding name. You probably don't think you have to look MIN up in the
manual to remember what it does. You've always used MIN. MIN is what you
would have used in any other programming language. You probably don't even
-remember- INF unless you just happened to look at the manual.
Now suppose you have an implementation with 32-bit integers for exacts and
floating point inexacts. If MAX-INDEX is 2148565200 (your implementation
supports very big vectors!) and N is 65552, then
(* n (+ 1 n)) ==> 4297130256
which doesn't fit in 32 bits. The closest floating point approximation
(assuming a 24-bit mantissa) happens to be 4297130496.0, which is -larger-
than the correct value. Thus
(/ (* n (+ 1 n)) 2) ==> 2148565248.0
And so (assuming MIN and INF behave as proposed):
A. (min max-index (/ (* n (+ 1 n)) 2)) ==> 2148565200
while
B. (inf max-index (/ (* n (+ 1 n)) 2)) ==> <some inexact>
yet the correct exact answer (obtained in an implementation where the * did
not overflow) would be 2148565128. Thus people who chose A will blindly
access the wrong element of the vector, while people who chose B will have
an error signaled by VECTOR-REF. People who chose A have a bug in their
code, while people who chose B do not.
Gee, Alan, this is fun! Best flame I've had this year.
!
∂21-Jul-89 2322 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: Fluid binding
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 23:22:40 PDT
Received: from gang-of-four.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB12020; Sat, 22 Jul 89 02:11:36 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22325;
21 Jul 89 18:47 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 18:47:20 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa22291;
21 Jul 89 18:42 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07856; Fri, 21 Jul 89 18:41:56 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 18:38:53 edt
Received: from Cabernet.ms by ArpaGateway.ms ; 21 JUL 89 15:34:16 PDT
Date: Fri, 21 Jul 89 15:33:13 PDT
From: Pavel.pa@xerox.com
Subject: Re: Fluid binding
In-Reply-To: <8907212220.AA22658@sde.hp.com>
To: rrrs-authors@zurich.ai.mit.edu
Cc: Pavel.pa@xerox.com
Message-Id: <890721-153416-4384@Xerox>
Your argument is like saying that COND is "bad" because it is hard to
implement in the semantics. I don't care about writing directly in
the semantics when the construct can be provided conveniently by user
code.
COND isn't at all hard to describe in the formal semantics.
Your model conceptually needs modification of the formal semantics,
while mine can be implemented trivially in a page of code. Which is
simpler?
Huh? Even your last example, written using dynamic-wind, wasn't entirely
in user code; it relied upon two mysterious primitives whose semantics I'm
still not sure of. That ain't user code by my definition. If you can't
write an implementation in R4RS Scheme, without reference to mysterious
primitives with implementation-specific semantics, then I claim it has to
go into the formal semantics.
Pavel
∂21-Jul-89 2331 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Regularization of list, vector, and string procedures
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 23:31:39 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA12043; Sat, 22 Jul 89 02:17:13 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25362;
21 Jul 89 23:23 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 23:23:30 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa25308;
21 Jul 89 23:19 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA10079; Fri, 21 Jul 89 23:19:33 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 23:16:27 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA28419; Fri, 21 Jul 89 20:19:07 pdt
Message-Id: <8907220319.AA28419@sde.hp.com>
Received: by hpesogg; Fri, 21 Jul 89 20:11:21 pdt
Date: Fri, 21 Jul 89 20:11:21 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: JMiller@crl.enet.dec.com
Cc: Pavel.pa@xerox.com, rrrs-authors@zurich.ai.mit.edu,
Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: jmiller@crl.dec.com's message of Fri, 21 Jul 89 09:30:45 EDT <8907211330.AA00412@peanut.DEC.COM>
Subject: Regularization of list, vector, and string procedures
Reply-To: jinx%hpesogg@sde.hp.com
Using the former concept, our definition of the Scheme functions would
need to be modified, but the argument in favor of the name change to
SUP/INF is inappropriate. Using the latter concept, there is an
argument that SUP/INF are superior names for what is actually
happening (based on the observation that SUP and INF of a set may
return limit elements that are not members of the set).
Can I have an informal show of hands? Please vote:
(1) Keep the names MAX and MIN, and make the semantics be
selector-like.
(2) Change the names to SUP and INF, and leave the semantics.
(3) Provide all 4 names and both semantics.
(4) Other.
If your answer depends on whether you are voting on a change to
R3.95RS or to P1178, please indicate.
I assume that 2 means that only SUP and INF are to be provided, and
that they are not guaranteed to return an eqv? element of the set.
If so, my preferences (in this order) are
2
3
1
P.S. -- In writing the above, I discovered a question I should be able
to answer but can't. First, notice that (max <set>) under
interpretation (b) (the current one) may signal an error even when all
elements of the set are real numbers -- due to the same implementation
restrictions. Question: are there real numbers that cause errors when
compared using < and so forth? I can't quite tell from reading
R3.95RS or P1178. Perhaps it is related to the requirement for
transitivity?
It obviously depends on the implementation. An important thing to
notice (for implementors), however, is that it is not hard to compare
a bignum and a flonum without coercing one to the other. Thus the
comparison predicates need not error out when either argument can't be
cast to the form of the other, they just have to be clever.
∂23-Jul-89 0001 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #167
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Jul 89 00:01:19 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA18719; Sun, 23 Jul 89 02:20:40 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07035;
23 Jul 89 0:08 EDT
Date: 23 JUL 89 00:06:13 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #167
To: Scheme@mc.lcs.mit.edu
Reply-To: Scheme@mc.lcs.mit.edu
Message-Id: <8907230008.aa07035@mintaka.lcs.mit.edu>
Scheme Digest #167 23 JUL 89 00:06:13 EDT
Today's Topics:
Cscheme posting
----------------------------------------------------------------------
Date: 19 Jul 89 13:54:30 GMT
From: Ross Judson <jarvis.csri.toronto.edu!utgpu!utzoo!dciem!nrcaer!sce!cognos!rossj@rutgers.edu>
Subject: Cscheme posting
Message-Id: <6592@cognos.UUCP>
As I understand it, Cscheme is a free (I hope!) implementation of
the scheme language. A month or two ago I read that somebody planned on
posting the most recent version. Has this been done? What's the status?
Unfortunately, I am unable to ftp, and, due to mailer screwups, unable to
mail out of this site at all. So posting is the only way I'll see it.
Does anybody from Ottawa or the region have it? I'd like to get in
touch if you do.
--
uucp - uunet!mitel!sce!cognos!rossj |people hate the generator
arpa/internet - rossj%cognos.uucp@uunet.uu.net |but love to light up the sky
------------------------------
End of Scheme Digest
********************
∂24-Jul-89 0904 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Jul 89 09:04:45 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA29460; Mon, 24 Jul 89 11:54:48 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22178;
24 Jul 89 11:46 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Jul 89 11:45:39 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa22154;
24 Jul 89 11:44 EDT
Received: from fafnir.think.com by Think.COM; Mon, 24 Jul 89 11:44:57 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 24 Jul 89 11:42:54 EDT
Received: by verdi.think.com; Mon, 24 Jul 89 11:42:50 EDT
Date: Mon, 24 Jul 89 11:42:50 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907241542.AA09125@verdi.think.com>
To: Alan@reagan.ai.mit.edu
Cc: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden's message of Fri, 21 Jul 89 16:57 EDT <19890721205725.0.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Numbers
Date: Fri, 21 Jul 89 16:57 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Quick, without thinking hard, decide whether would you write
A. (vector-ref v (min max-index (/ (* n (+ 1 n)) 2)))
or
B. (vector-ref v (inf max-index (/ (* n (+ 1 n)) 2))) ?
I'll bet that most people would answer A. After all, MIN is the familiar
sounding name. You probably don't think you have to look MIN up in the
manual to remember what it does. You've always used MIN. MIN is what you
would have used in any other programming language. You probably don't even
-remember- INF unless you just happened to look at the manual.
Now suppose you have an implementation with 32-bit integers for exacts and
floating point inexacts. If MAX-INDEX is 2148565200 (your implementation
supports very big vectors!) and N is 65552, then
(* n (+ 1 n)) ==> 4297130256
which doesn't fit in 32 bits. The closest floating point approximation
(assuming a 24-bit mantissa) happens to be 4297130496.0, which is -larger-
than the correct value. Thus
(/ (* n (+ 1 n)) 2) ==> 2148565248.0
And so (assuming MIN and INF behave as proposed):
A. (min max-index (/ (* n (+ 1 n)) 2)) ==> 2148565200
while
B. (inf max-index (/ (* n (+ 1 n)) 2)) ==> <some inexact>
yet the correct exact answer (obtained in an implementation where the * did
not overflow) would be 2148565128. Thus people who chose A will blindly
access the wrong element of the vector, while people who chose B will have
an error signaled by VECTOR-REF. People who chose A have a bug in their
code, while people who chose B do not.
Depends on why I put the MIN in there. If I put it in precisely to
guard against indexing off the end of the vector when running in
broken implementations that think 32 bits is enough to count anything
interesting at all, then the program is doing its job, and MIN is
exactly what I wanted. (Then again, I might have written
(vector-ref v (if (odd? n) (* n (/ (+ 1 n) 2)) (* (/ n 2) (+ 1 n))))
to be really safe.)
--Guy
∂24-Jul-89 0945 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu Regularization of list, vector, and string procedures
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Jul 89 09:45:09 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA29912; Mon, 24 Jul 89 12:27:42 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22525;
24 Jul 89 12:18 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Jul 89 12:18:19 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa22506;
24 Jul 89 12:15 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA29684; Mon, 24 Jul 89 12:15:28 EDT
Received: from life.ai.mit.edu (ai.mit.edu) by zurich.ai.mit.edu; Mon, 24 Jul 89 12:11:47 edt
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA29246; Mon, 24 Jul 89 11:33:28 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA22748; Mon, 24 Jul 89 08:29:18 PDT
Date: Mon, 24 Jul 89 08:29:18 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907241529.AA22748@sesame.Stanford.EDU>
To: jinx%hpesogg@sde.hp.com
Cc: Pavel.pa@xerox.com, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: "Guillermo J. Rozas"'s message of Fri, 21 Jul 89 04:55:30 pdt <8907211156.AA10576@sde.hp.com>
Subject: Regularization of list, vector, and string procedures
Date: Fri, 21 Jul 89 04:55:30 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
Reply-To: jinx%hpesogg@sde.hp.com
I'd prefer to avoid generic procedures at the lowest levels of Scheme.
Why not have LIST-APPLY, VECTOR-APPLY, and STRING-APPLY, by analogy with
LIST-LENGTH, VECTOR-LENGTH, and STRING-LENGTH etc?
Assuming that ``apply'' is initially bound to the same value as
``list-apply'', I don't object to this proposal. It will be amusing to see
if I ever find a use for either of ``vector-apply'' or ``string-apply''.
I don't see a point to STRING-APPLY or VECTOR-APPLY (except to be used
with STRING or VECTOR to copy a string or vector). I think we should
leave APPLY alone for the following reasons:
- Apply is not really an operation on lists. It is a hook into the
procedure calling mechanism of the language so that procedures with
arbitrary arity can be called with arbitrary numbers of arguments.
Applying to lists is traditional, although funny in the same way that
arbitrary arity procedures (procedures with dotted lambda lists) build
lists.
The right way to fix APPLY is not to generalize it along its spurious
direction, but to devise some way by which we can drop user data
structures altogether from this hook into the system, for example, by
designing an alternative based on procedures.
This solution would be fine with me. What is not acceptable from a symmetry
point of view is to leave things unchanged. Either apply must work using some
new form or there must be versions for each of the reasonable data types.
- The kind of manipulation where apply is used is more conveniently
done on lists than on any other data structures.
Is this claim that it is more convenient from the user's perspective or the
language implementors? Some evidence of either would be greatly appreciated.
It is also natural
to think of argument lists as lists, rather than vectors or strings.
Maybe to some people. I find this argument far from persuasive.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂24-Jul-89 0948 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu Regularization of list, vector, and string procedures
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Jul 89 09:47:49 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA29941; Mon, 24 Jul 89 12:30:58 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22653;
24 Jul 89 12:23 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Jul 89 12:24:00 EDT
Received: from [128.52.32.80] by mintaka.lcs.mit.edu id aa22553;
24 Jul 89 12:19 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA29736; Mon, 24 Jul 89 12:19:01 EDT
Received: from life.ai.mit.edu (ai.mit.edu) by zurich.ai.mit.edu; Mon, 24 Jul 89 12:15:47 edt
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA29075; Mon, 24 Jul 89 11:25:10 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA22683; Mon, 24 Jul 89 08:18:30 PDT
Date: Mon, 24 Jul 89 08:18:30 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907241518.AA22683@sesame.Stanford.EDU>
To: JMiller@crl.enet.dec.com
Cc: Pavel.pa@xerox.com, rrrs-authors@zurich.ai.mit.edu,
Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: jmiller@crl.dec.com's message of Fri, 21 Jul 89 09:30:45 EDT <8907211330.AA00412@peanut.DEC.COM>
Subject: Regularization of list, vector, and string procedures
Can I have an informal show of hands? Please vote:
I do not care about the semantics nearly so much as the names. (Yes, I know
this is a wierd position.) I feel that the names MAX and MIN should be bound
to functions with some reasonable semantics. Whether RNRS has SUP and INF in
addition due to nuances in the definitions is not very important to me. I
would like the niave user who does not care about these nuances to be able to
find the functions he/she needs (i.e., MAX and MIN) with the greatest ease
possible.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂24-Jul-89 1216 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@mrloog.la.tek.com Re: Regularization of apply; Show of hands
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Jul 89 12:16:37 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01776; Mon, 24 Jul 89 15:03:07 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24635;
24 Jul 89 14:52 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Jul 89 14:45:17 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24476;
24 Jul 89 14:43 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01423; Mon, 24 Jul 89 14:43:08 EDT
Received: from RELAY.CS.NET (relay.cs.net) by zurich.ai.mit.edu; Mon, 24 Jul 89 14:39:56 edt
Received: from tektronix.tek.com by RELAY.CS.NET id aa27237; 24 Jul 89 14:36 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA07628; Mon, 24 Jul 89 11:38:03 PDT
Received: by dadla.LA.TEK.COM (5.51/6.24)
id AA08842; Mon, 24 Jul 89 11:32:05 PDT
Received: by mrloog.la.tek.com (1.2/7.1)
id AA14325; Mon, 24 Jul 89 11:37:00 pdt
Message-Id: <8907241837.AA14325@mrloog.la.tek.com>
To: rrrs-authors@zurich.ai.mit.edu, Scheme-Standard@wheaties.ai.mit.edu
Subject: Re: Regularization of apply; Show of hands
In-Reply-To: Your message of Mon, 24 Jul 89 08:18:30 PDT.
<8907241518.AA22683@sesame.Stanford.EDU>
Date: 24 Jul 89 11:36:56 PDT (Mon)
From: kend%mrloog.la.tek.com@relay.cs.net
> The right way to fix APPLY is not to generalize it along its spurious
> direction, but to devise some way by which we can drop user data
> structures altogether from this hook into the system, for example, by
> designing an alternative based on procedures.
I would prefer that APPLY be applicable only to multiple values. For
that matter, I favor multiple value rest arguments--dropping rest *lists*
altogether.
> --Jim Miller
> Can I have an informal show of hands? Please vote:
> (1) Keep the names MAX and MIN, and make the semantics be
> selector-like.
> (2) Change the names to SUP and INF, and leave the semantics.
> (3) Provide all 4 names and both semantics.
> (4) Other.
> If your answer depends on whether you are voting on a change to
> R3.95RS or to P1178, please indicate.
For both R3.95RS and P1178, I prefer SUP and INF. Max and Min should be
defined in the Yellow Pages as macros (when we get macros). I would not
object to adding definition (as selectors) MAN and MIN to R3.95RS. MAX
and MIN are obviously too radical for P1178 [and--assuming macros--can be
trivially implemented].
-Ken Dickey kend@mrloog.LA.TEK.COM
∂24-Jul-89 1255 @mc.lcs.mit.edu,@life.ai.mit.edu:Alan@REAGAN.ai.mit.edu Regularization of list, vector, and string procedures
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Jul 89 12:55:42 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02213; Mon, 24 Jul 89 15:39:55 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25075;
24 Jul 89 15:29 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Jul 89 15:29:40 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa25065;
24 Jul 89 15:26 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02076; Mon, 24 Jul 89 15:26:47 EDT
Received: from REAGAN.AI.MIT.EDU (reagan.ai.mit.edu) by zurich.ai.mit.edu; Mon, 24 Jul 89 15:23:25 edt
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 239933; Mon 24-Jul-89 15:26:31 EDT
Date: Mon, 24 Jul 89 15:26 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Subject: Regularization of list, vector, and string procedures
To: JMiller@crl.enet.dec.com
Cc: Pavel.pa@xerox.com, rrrs-authors@zurich.ai.mit.edu,
Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: <8907211330.AA00412@peanut.DEC.COM>
Message-Id: <19890724192626.3.ALAN@PIGPEN.AI.MIT.EDU>
Date: Fri, 21 Jul 89 09:30:45 EDT
From: jmiller@crl.dec.com
...
Can I have an informal show of hands? Please vote:
(1) Keep the names MAX and MIN, and make the semantics be
selector-like.
(2) Change the names to SUP and INF, and leave the semantics.
(3) Provide all 4 names and both semantics.
(4) Other.
I vote 4. There should be no procedures named SUP and INF. We should
have procedures named MIN and MAX that only return exact numbers given
exact arguments.
I guess that the fact that my opinion didn't even make your list of options
means that I'm not making myself clear.
If your answer depends on whether you are voting on a change to
R3.95RS or to P1178, please indicate.
My opinion applies to RnRS only.
∂24-Jul-89 1549 @mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Jul 89 15:49:37 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04267; Mon, 24 Jul 89 18:33:54 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26955;
24 Jul 89 18:31 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 24 Jul 89 18:32:10 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 240033; Mon 24-Jul-89 18:31:20 EDT
Date: Mon, 24 Jul 89 18:31 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Subject: Numbers
To: gls@think.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8907241542.AA09125@verdi.think.com>
Message-Id: <19890724223118.4.ALAN@PIGPEN.AI.MIT.EDU>
Date: Mon, 24 Jul 89 11:42:50 EDT
From: Guy Steele <gls@think.com>
Date: Fri, 21 Jul 89 16:57 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
...
And so (assuming MIN and INF behave as proposed):
A. (min max-index (/ (* n (+ 1 n)) 2)) ==> 2148565200
while
B. (inf max-index (/ (* n (+ 1 n)) 2)) ==> <some inexact>
yet the correct exact answer (obtained in an implementation where
the * did not overflow) would be 2148565128. Thus people who chose
A will blindly access the wrong element of the vector, while people
who chose B will have an error signaled by VECTOR-REF. People who
chose A have a bug in their code, while people who chose B do not.
Depends on why I put the MIN in there. If I put it in precisely to
guard against indexing off the end of the vector when running in broken
implementations that think 32 bits is enough to count anything
interesting at all, then the program is doing its job, and MIN is
exactly what I wanted....
No matter what gonzo behavior is proposed for MIN, you can -always- defend
the resulting behavior by saying "well, perhaps that's what I wanted".
Well, suppose it wasn't what I wanted. Suppose I was computing a histogram
of some sort. I might be pretty puzzled by the fact that bucket 2148565200
had so many entries. Or perhaps I wouldn't notice at all. Perhaps I
publish my results, and then someday somebody gets a lethal dose of
radiation as a result. See? I can make up stories too.
Out of frustration, I will now change my position.
1. I now propose that all the numeric predicates should signal an error
when given any inexact arguments. I propose a parallel family of numeric
predicates with names like "%=" and "%ODD?" that behave unsafely, as the
current numeric predicates do.
2. I propose that numeric functions, such as LOG and /, that can signal
errors at certain points in the domain of one of their arguments, -must-
signal an error if that argument is inexact. I propose to add a parallel
family of numeric functions with names like "%LOG" and "%/" that behave
unsafely, as the current numeric functions do. (For uniformity, we might
have both + and %+, even thought they behave identically.)
3. I propose to change the names of EXACT? and INEXACT? to be "%EXACT?"
and "%INEXACT?".
4. Finally, I propose we add %MIN and %MAX to compute the unsafe minimum
and maximum that seems so popular.
With these changes in place, Scheme would have the following property:
A program that does not contain a "%", will compute the same exact
numeric result in all Scheme implementations in which it doesn't signal
an error or return an inexact result.
(My proposal is actually stronger than necessary to insure this property.
In an implementations that use representations other than floating point
for inexacts, it may be possible to reliably answer questions such as
(< X Y) reliably, so an error need not be signaled in that case. I could
have simply proposed that implementations can do whatever they want, as
long as they don't violate that property.)
I realize that nobody will take me seriously on this. But nobody was
taking me seriously anyway.
∂25-Jul-89 1259 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Jul 89 12:58:07 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA16380; Tue, 25 Jul 89 15:41:12 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11442;
25 Jul 89 15:27 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Jul 89 15:27:19 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa11396;
25 Jul 89 15:21 EDT
Received: from fafnir.think.com by Think.COM; Tue, 25 Jul 89 15:21:40 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 25 Jul 89 15:19:30 EDT
Received: by verdi.think.com; Tue, 25 Jul 89 14:23:01 EDT
Date: Tue, 25 Jul 89 14:23:01 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907251823.AA27924@verdi.think.com>
To: Alan@reagan.ai.mit.edu
Cc: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden's message of Mon, 24 Jul 89 18:31 EDT <19890724223118.4.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Numbers
Date: Mon, 24 Jul 89 18:31 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Date: Mon, 24 Jul 89 11:42:50 EDT
From: Guy Steele <gls@think.com>
Date: Fri, 21 Jul 89 16:57 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
...
And so (assuming MIN and INF behave as proposed):
A. (min max-index (/ (* n (+ 1 n)) 2)) ==> 2148565200
while
B. (inf max-index (/ (* n (+ 1 n)) 2)) ==> <some inexact>
yet the correct exact answer (obtained in an implementation where
the * did not overflow) would be 2148565128. Thus people who chose
A will blindly access the wrong element of the vector, while people
who chose B will have an error signaled by VECTOR-REF. People who
chose A have a bug in their code, while people who chose B do not.
Depends on why I put the MIN in there. If I put it in precisely to
guard against indexing off the end of the vector when running in broken
implementations that think 32 bits is enough to count anything
interesting at all, then the program is doing its job, and MIN is
exactly what I wanted....
No matter what gonzo behavior is proposed for MIN, you can -always- defend
the resulting behavior by saying "well, perhaps that's what I wanted".
No matter for what sensible reason I wrote "MIN" in my code instead
of "INF", you can -always- attack my claim that this example supports a
general rationale by saying, "No matter what gonzo behavior...."
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
Well, suppose it wasn't what I wanted. Suppose I was computing a histogram
of some sort. I might be pretty puzzled by the fact that bucket 2148565200
had so many entries. Or perhaps I wouldn't notice at all. Perhaps I
publish my results, and then someday somebody gets a lethal dose of
radiation as a result. See? I can make up stories too.
Well, if I were to examine the code and spot -either- a MIN or INF
that clipped the bucket number to 2148565200, I think I would be
led to reason about that code a little more closely...
--Guy
P.S. This is fun.
∂25-Jul-89 1454 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Regularization of apply; Show of hands
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Jul 89 14:54:03 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA17769; Tue, 25 Jul 89 17:33:52 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13066;
25 Jul 89 17:24 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Jul 89 17:23:24 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12984;
25 Jul 89 17:20 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA17539; Tue, 25 Jul 89 17:20:23 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Tue, 25 Jul 89 17:17:06 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA05849; Tue, 25 Jul 89 14:20:02 pdt
Message-Id: <8907252120.AA05849@sde.hp.com>
Received: by hpesogg; Tue, 25 Jul 89 14:19:10 pdt
Date: Tue, 25 Jul 89 14:19:10 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: kend%mrloog.la.tek.com@relay.cs.net
Cc: rrrs-authors@zurich.ai.mit.edu, Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: kend%mrloog.la.tek.com@relay.cs.net's message of 24 Jul 89 11:36:56 PDT (Mon) <8907241837.AA14325@mrloog.la.tek.com>
Subject: Regularization of apply; Show of hands
Reply-To: jinx%hpesogg@sde.hp.com
Date: 24 Jul 89 11:36:56 PDT (Mon)
From: kend%mrloog.la.tek.com@relay.cs.net
> The right way to fix APPLY is not to generalize it along its spurious
> direction, but to devise some way by which we can drop user data
> structures altogether from this hook into the system, for example, by
> designing an alternative based on procedures.
I would prefer that APPLY be applicable only to multiple values. For
that matter, I favor multiple value rest arguments--dropping rest *lists*
altogether.
What do you mean by multiple values?
Do you mean something like LAMBDA*'s & pseudo-objects?
If you mean something along the more traditional lines, you have just
pushed the problem one level deeper, since your multiple value
receivers are also expressed in lambda notation and therefore you need
to have dotted lists.
∂25-Jul-89 1524 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com Regularization of apply; Show of hands
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Jul 89 15:24:09 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA18275; Tue, 25 Jul 89 18:09:33 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13466;
25 Jul 89 17:56 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Jul 89 17:56:25 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa13445;
25 Jul 89 17:52 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA18030; Tue, 25 Jul 89 17:52:06 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Tue, 25 Jul 89 17:48:51 edt
Received: from fafnir.think.com by Think.COM; Tue, 25 Jul 89 17:45:04 EDT
Received: from verdi.think.com by fafnir.think.com; Tue, 25 Jul 89 17:42:58 EDT
Received: by verdi.think.com; Tue, 25 Jul 89 17:42:53 EDT
Date: Tue, 25 Jul 89 17:42:53 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907252142.AA04994@verdi.think.com>
To: jinx%hpesogg@sde.hp.com
Cc: kend%mrloog.la.tek.com@relay.cs.net, rrrs-authors@zurich.ai.mit.edu,
Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Tue, 25 Jul 89 14:19:10 pdt <8907252120.AA05849@sde.hp.com>
Subject: Regularization of apply; Show of hands
Date: Tue, 25 Jul 89 14:19:10 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
Date: 24 Jul 89 11:36:56 PDT (Mon)
From: kend%mrloog.la.tek.com@relay.cs.net
> The right way to fix APPLY is not to generalize it along its spurious
> direction, but to devise some way by which we can drop user data
> structures altogether from this hook into the system, for example, by
> designing an alternative based on procedures.
I would prefer that APPLY be applicable only to multiple values. For
that matter, I favor multiple value rest arguments--dropping rest *lists*
altogether.
What do you mean by multiple values?
Do you mean something like LAMBDA*'s & pseudo-objects?
If you mean something along the more traditional lines, you have just
pushed the problem one level deeper, since your multiple value
receivers are also expressed in lambda notation and therefore you need
to have dotted lists.
This strikes me as almost certainly a reference to the "rest values"
described by Dybvig and Hieb in Proc. 1988 ACM Conf. Lisp and Functional
Programming. Note that while that paper speaks of rest variables,
it does not state in so many words that the collection of values
associated with such a variables constitutes any sort of object,
pseudo- or otherwise.
By the way, I think that this idea in lambda* has much to recommend it.
(Then again, the ever-mythical "sufficiently smart compiler" ought to
be able to use data flow analysis to eliminate many, though not all,
uses of rest-lists...)
--Guy
∂25-Jul-89 1909 @mc.lcs.mit.edu,@life.ai.mit.edu:KMP@stony-brook.scrc.symbolics.com INF/SUP/MIN/MAX, LIST?/PROPER-LIST?, APPLY
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Jul 89 19:08:48 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA20223; Tue, 25 Jul 89 21:39:21 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa15563;
25 Jul 89 21:08 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Jul 89 20:55:21 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa14514;
25 Jul 89 19:36 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA19155; Tue, 25 Jul 89 19:36:01 EDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (stony-brook.scrc.symbolics.com) by zurich.ai.mit.edu; Tue, 25 Jul 89 19:32:47 edt
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 631474; 25 Jul 89 19:06:48 EDT
Date: Tue, 25 Jul 89 19:06 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: INF/SUP/MIN/MAX, LIST?/PROPER-LIST?, APPLY
To: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: <8907211330.AA00412@peanut.DEC.COM>
Message-Id: <19890725230639.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
As most of you know, I don't use Scheme regularly. But I have in the
past and might again, and I do care about it. I offer my advice as that
of an informed observer and potential future user...
- I have advocated a PROPER-LIST? function in T ever since
its creation. It was there for a while, and perhaps later
removed. I have no idea what its current state is. I
definitely feel strongly that writing a circularity-checker
is easy to do but not everyone knows how to do it. It's
easy to interleave circularity checking with the atom/null
check that PROPER-LIST? will do, to give a nice overall effect.
I strongly favor the introduction of PROPER-LIST?
If the name LIST? were introduced, I feel quite strongly
that it should parallel what LISTP does in Lisp because there
are too many people who've gone back and forth and it was
just too confusing going from Maclisp's LISTP to CL's LISTP
without having that incompatibility hassle introduced all over
again. I think that for people who go to care to construct
only proper lists, CL's LISTP is the right cross between
efficiency and reliability.
If everyone will not agree to put LIST? in as a synonym for
(LAMBDA (X) (OR (NULL? X) (PAIR? X))), then everyone should
agree to leave it out and go for PROPER-LIST? (on which I think
we can agree about the definition) so that implementations that
want to put LIST? in compatibly can do so.
As a -complete- aside, I would be quite happy to also see a
library function which would be described in CL notation by
CIRCULAR? list &KEY (path #'CDR) (end-test #'NULL?)
[and which you could set up argument-wise however you liked
in Scheme], but I don't expect there to be a enough support
for that to bother pursuing it at this late date.
- With regard to MAX/MIN and INF/SUP, let me just say that there
are two approaches to designing a language: you can figure out
what you can understand/implement and then provide that, or you
can figure out what users want/need and try to figure a way to
provide that.
If users were crying out for INF/SUP, then I think you should
consider providing it, but I've never heard anyone ask for it.
I have heard them ask for MAX/MIN and just plain think they
should be provided. The importance of returning an EQV? value
is that I may be doing selection from a list of items, and I may
be planning to later try to use MEMBER? or ASSOC? some such to
later find the element again in the list. If MAX/MIN `destroys'
the identity of the argument and gives me back something which
isn't really the same, then my algorithms may fail. I'm big on
object identity and <<uh, what's the opposite-- little??>> on
things that casually disregard it.
In my opinion, the whole INF/SUP debate comes down to a haughty
disregard on the part of some designers for a clearly expressed
need on the part of users. I've not been convinced by any discussion
I've seen that the MAX/MIN users are calling for is impossible to
provide. What it sounds like to me is that the implementors are
busy building a wall that is going to impede entry into the Scheme
community because potential users are going to have to be even
more mathematically anal than they already have to be in order to
feel comfortable with what's provided. When people talk about max
in English, they say "give me the maximum of" not "a maximum of".
I think most "normal people" (like my mom or J. random programmer
who hasn't got a doctorate in advanced degree in math) expect a
uniquely determined result which is IN the initial set.
I think we should offer that. If we offer something else, that's fine.
But don't do it on MAX. And don't be so stubborn that you can't provide
the MAX that 99.9% of your users are clearly asking for.
Note: I personally wouldn't mind if MAX -failed- (reliably signalled
an error or however you scheme guys say that) in the case where there was
a potential problem due to exactness. I wouldn't mind if it was required
that all arguments be exact or that all be inexact. I only care that if
I do get back a result, it's described by the rules that I intuitively use.
But I suspect others would find this too tedious, and anyway, it's
inconsistent with the idea that <, etc. can compare exact and inexact numbers.
After all, there's a fundamental problem underlying all inexact comparisons
that depending on -how- inexact two numbers are, the one which -appears- less
may not really be. Once you've opened that door, it's not clear where to
start drawing the line. So given all that, I think the right thing is just
to assume every number is correct locally within the operation, and then
to just return the `biggest' number with its original exactness and leave
it at that.
- I think APPLY should be left alone. It should do the job needed in order
to describe how to apply functions in forms. Since lists are all that's
needed to express forms, I think they're all that's needed in order to
describe applcication.
APPLY definitely should not be extended to vecotrs unless you make
it so that vectors are valid forms for evaluation (i guess with the
operator in slot 0 and the args in successive slots), but i don't
see any point to that either. It just reduces error checking.
I don't think extending apply to deal with multiple values is a good
idea for pretty much the same reason. Also because I think the idea
of turning APPLY (currently a normal function) into something that
could grok multiple values is a good change. If you want a new special
form (or keyword, i guess you call them), call it something other than
APPLY so as not to confuse the whole universe. If you call it something
else, I don't mind having it around--but then I don't think it should
bother hacking lists... and I'd still keep APPLY, both for historical
reasons and because it's useful even now.
Do not undervalue the importance of leaving holes in your syntactic
space. The more things you make "defined", the less robust your
language becomes because everything means something. The problem is
that the only chance you have to catch a programmer babbling is when
he says something so obviously wrong that you can flag it without
knowing the context. Unless you have a compelling reason to make
things that are currently "obviously wrong" into "meaningful", then
you should think twice about giving up your freedom to recognize
problems. This is -especially- true in a language like Scheme which
has such an underdeveloped notion of error handling and where users can
(at least, if the spec is all they have to go on) really rely on nothing
much to catch them if they venture beyond the clearly specified range
of what they're -supposed to- have done.
I hope these comments are of help in resolving the latest flurry of
conflicts.
By the way, one thing the CL community has done well which the Scheme community
has done poorly, is to document in a modular fashion all the design rationales
for ongoing changes to the language so that they aren't doomed to repeat the
same arguments over and over again. It would be nice if the Scheme community
started to move toward a similar bookkeeping strategy. Many of these arguments
hit me with a real sense of deja vu which it seems to me could have been
avoided.
∂25-Jul-89 1915 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Regularization of apply (long)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Jul 89 19:15:23 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA20399; Tue, 25 Jul 89 22:02:08 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa15872;
25 Jul 89 21:24 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Jul 89 20:56:38 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa14805;
25 Jul 89 20:03 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA19331; Tue, 25 Jul 89 20:03:31 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Tue, 25 Jul 89 20:00:16 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA10241; Tue, 25 Jul 89 17:02:58 pdt
Message-Id: <8907260002.AA10241@sde.hp.com>
Received: by hpesogg; Tue, 25 Jul 89 17:02:14 pdt
Date: Tue, 25 Jul 89 17:02:14 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: gls@think.com
Cc: kend%mrloog.la.tek.com@relay.cs.net, rrrs-authors@zurich.ai.mit.edu,
Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: Guy Steele's message of Tue, 25 Jul 89 17:42:53 EDT <8907252142.AA04994@verdi.think.com>
Subject: Regularization of apply (long)
Reply-To: jinx%hpesogg@sde.hp.com
What do you mean by multiple values?
Do you mean something like LAMBDA*'s & pseudo-objects?
If you mean something along the more traditional lines, you have just
pushed the problem one level deeper, since your multiple value
receivers are also expressed in lambda notation and therefore you need
to have dotted lists.
This strikes me as almost certainly a reference to the "rest values"
described by Dybvig and Hieb in Proc. 1988 ACM Conf. Lisp and Functional
Programming. Note that while that paper speaks of rest variables,
it does not state in so many words that the collection of values
associated with such a variables constitutes any sort of object,
pseudo- or otherwise.
kend's comment may well have been a reference to Dybvig and Hieb's
"rest values", which is precisely what I was asking.
Although I agree that there are interesting issues in lambda*, I think
that lambda* mixes up too many concepts and imposes implementation
restrictions that I'm not sure I like.
I envision something more primitive, and completely different. I
think that using lists, vectors, or special values to collect and pass
arbitrary numbers of arguments is spurious. Specific data structures
should be introduced by the user according to convenience or intent.
The arbitrary arity mechanism in the language should not be based on
arbitrary data aggragates at all, but on something more primitive, and
procedures (I think) are a good choice.
As a "proof of concept" I will present an example, which in no way
should be taken as a proposal for RnRs, but merely as a hint of what I
would like to see.
Consider the two "primitives" SUPPLY-ARGUMENTS and
MAKE-ARGUMENTS-COLLECTOR. Sample implementations are provided below
in terms of APPLY and "dot notation".
SUPPLY-ARGUMENTS is analogous to APPLY. It is a mechanism for
suppliying arguments to a procedure without knowing at programming
time exactly how many arguments are being supplied. SUPPLY-ARGUMENTS
coroutines with the argument supplier, which provides one argument at
a time. SUPPLY-ARGUMENTS calls all of them, and eventually invokes
the procedure on all the arguments collected.
MAKE-ARGUMENTS-COLLECTOR is analogous in intent to "dot notation". It
is a mechanism for constructing a procedure that accepts any number of
arguments. The essential idea is that collecting any number of arguments
is a reduction process with a null-value (the terminator) and a "combiner"
which combines the current argument with the combination of the remaining
arguments. There is also a "wrapper" which allows some further processing
after all the arguments have been processed.
These "primitives" are somewhat clumsy and I have not thought about
their native implementation carefully, but are a relatively good way
to describe procedures of arbitrary arity without reference to
individual data structures.
Sample implementation in terms of apply and "dot notation":
;;; New "primitives"
(define (supply-arguments procedure supplier)
(define (collect-loop l supplier)
(supplier
(lambda (next new-supplier)
(collect-loop (cons next l)
new-supplier))
(lambda ()
(APPLY procedure (reverse l)))))
(collect-loop '() supplier))
(define (make-arguments-collector wrapper combiner terminator)
(lambda ARG-LIST
(define (process l)
(if (null? l)
(terminator)
(combiner (car l)
(process (cdr l)))))
(wrapper (process ARG-LIST))))
Examples of their use:
;; This is the traditional 2-argument apply.
(define (invoke-on-list procedure l)
(define (supply l collect-next end)
(if (null? l)
(end)
(collect-next (car l)
(lambda (next-collector next-end)
(supply (cdr l) next-collector next-end)))))
(supply-arguments
procedure
(lambda (collect end)
(supply l collect end))))
(define (invoke-on-vector procedure v)
(define (supply i collect-next end)
(if (>= i (vector-length v))
(end)
(collect-next (vector-ref v i)
(lambda (next-collector next-end)
(supply (1+ i) next-collector next-end)))))
(supply-arguments
procedure
(lambda (collect end)
(supply 0 collect end))))
(define nary-+
(make-arguments-collector (lambda (x) x)
+
(lambda () 0)))
(define count-args
(make-arguments-collector (lambda (x) x)
(lambda (x rest)
(1+ rest))
(lambda () 0)))
(define list
(make-arguments-collector (lambda (x) x)
cons
(lambda () '())))
(define vector
(make-arguments-collector list->vector
cons
(lambda () '())))
(define cons*
(let ((tag (cons 'cons*-tag '())))
(make-arguments-collector
(lambda (result)
(if (eq? result tag)
(error "cons*: No arguments supplied")
result))
(lambda (new tail)
(if (eq? tail tag)
new
(cons new tail)))
(lambda () tag))))
;; This is the full-fledged apply.
(define apply
(make-arguments-collector
(lambda (result)
(case (car result)
((none-provided)
(error "apply: No arguments supplied"))
((one-provided)
((cdr result)))
(else
(invoke-on-list (cadr result)
(cddr result)))))
(lambda (new tail)
(case (car tail)
((none-provided)
(cons 'one-provided new))
(else
(cons 'normal
(cons new (cdr tail))))))
(lambda ()
(cons 'none-provided '()))))
∂25-Jul-89 2003 @mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Jul 89 20:03:33 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA20760; Tue, 25 Jul 89 22:53:21 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16904;
25 Jul 89 22:41 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 25 Jul 89 22:42:08 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 240964; Tue 25-Jul-89 22:41:20 EDT
Date: Tue, 25 Jul 89 22:41 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Subject: Numbers
To: gls@think.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8907251823.AA27924@verdi.think.com>
Message-Id: <19890726024117.0.ALAN@PIGPEN.AI.MIT.EDU>
Date: Tue, 25 Jul 89 14:23:01 EDT
From: gls@Think.COM (Guy Steele)
...
Well, if I were to examine the code and spot -either- a MIN or INF
that clipped the bucket number to 2148565200, I think I would be
led to reason about that code a little more closely...
But INF will -never- clip to the wrong bucket! That's the whole point of
the example! INF doesn't shaft you by returning an exact number when it
doesn't know the answer exactly, it return an inexact number, and then
VECTOR-REF signals an error. With INF, you learn of a limitation in the
arithmetic of your Scheme implementation (so that perhaps you can rewrite
your code in the clever way you suggested the other day). With MIN, your
program just references the wrong element of the vector.
(No need to point out that I have again returned to assuming that
2148565200 is the "wrong" bucket. Again, if what MIN does just happens to
do what you really wanted, whatever that may be, then of course you will
have no cause to complain about its behavior. But assuming that you put
that call to MIN/INF in there because you thought you were computing a
histogram, and you wanted to count all the huge values in the -last-
bucket, then 2148565200 is an error.)
∂26-Jul-89 0359 @mc.lcs.mit.edu,@life.ai.mit.edu:Alan@reagan.ai.mit.edu INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89 03:59:19 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AB24395; Wed, 26 Jul 89 06:48:58 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20216;
26 Jul 89 3:43 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 03:43:29 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20187;
26 Jul 89 3:37 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA23380; Wed, 26 Jul 89 03:37:29 EDT
Received: from REAGAN.AI.MIT.EDU (reagan.ai.mit.edu) by zurich.ai.mit.edu; Wed, 26 Jul 89 03:34:15 edt
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 240992; Wed 26-Jul-89 01:15:19 EDT
Date: Wed, 26 Jul 89 01:15 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Subject: INF/SUP/MIN/MAX
To: KMP@stony-brook.scrc.symbolics.com
Cc: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: <19890725230639.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-Id: <19890726051514.2.ALAN@PIGPEN.AI.MIT.EDU>
Date: Tue, 25 Jul 89 19:06 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
...
If users were crying out for INF/SUP, then I think you should consider
providing it, but I've never heard anyone ask for it.
I have heard them ask for MAX/MIN and just plain think they should be
provided.
I've never heard users asking for the notion of exactness/inexactness at
all. Ask them what they want, and they will probably tell you that they
want IEEE floating point. As I have said before, I think it would be 100%
reasonable for Scheme to do what every other language does, and adopt some
reasonable set of rules for the behavior of floating point. Unfortunately,
Scheme decided to go in a different direction. Inexact numbers are not
just another name for floating point, so we have -already- decided to give
users something other than what they would ask for. What we are arguing
about here, are the -consequences- of that decision for the function MIN.
I was under the impression that the consistency of the language mattered,
not just what the users think they want before you have a chance to explain
the issues to them.
The importance of returning an EQV? value is that I may be
doing selection from a list of items, and I may be planning to later
try to use MEMBER? or ASSOC? some such to later find the element again
in the list. If MAX/MIN `destroys' the identity of the argument and
gives me back something which isn't really the same, then my algorithms
may fail. I'm big on object identity and <<uh, what's the opposite--
little??>> on things that casually disregard it.
I'd be interested in seeing examples of code that depends on the identity
of the value returned by MAX or MIN. I just checked through all of my
Scheme code, and I didn't find any instances in which it mattered.
Typically I found that the result was fed into a function like +, - or *.
Once the result was passed as the first argument to MAKE-STRING. In the
case of MAKE-STRING, having MAX return an inexact number when any argument
was inexact provides the kind of error checking I've been flaming to Steele
about. I'm a fan of object identity too, but not at the expense of
returning a incorrect result.
In my opinion, the whole INF/SUP debate comes down to a haughty
disregard on the part of some designers for a clearly expressed need on
the part of users.
I don't see anybody else here defending this point of view, so it must be
me who is being "haughty". Below, I apparently become "anal" and
"stubborn". I must say, it's more fun arguing with Steele.
I've not been convinced by any discussion I've seen
that the MAX/MIN users are calling for is impossible to provide. What
it sounds like to me is that the implementors are busy building a wall
that is going to impede entry into the Scheme community because
potential users are going to have to be even more mathematically anal
than they already have to be in order to feel comfortable with what's
provided. When people talk about max in English, they say "give me the
maximum of" not "a maximum of". I think most "normal people" (like my
mom or J. random programmer who hasn't got a doctorate in advanced
degree in math) expect a uniquely determined result which is IN the
initial set. I think we should offer that. If we offer something
else, that's fine. But don't do it on MAX. And don't be so stubborn
that you can't provide the MAX that 99.9% of your users are clearly
asking for.
Most "normal people" expect the distributive law to be true too, but with
inexact numbers, it won't necessarily be. In English we can certainly say
that + returns "the sum" of two numbers, but once inexact numbers are
involved any given Scheme implementation can only claim to compute a
representation of that sum.
(+ 1.0 1e20) ==> 1.0
Having added something non-zero to an inexact 1, should I be concerned that
the result is EQV? to the argument? My mom would probably complain that
the answer should be -different-, yet here Scheme might even return
something that is EQ?. Suppose I was planning on feeding this result to
MEMBER? or ASSOC? -- isn't this just as bad as what MAX does?
Inexact numbers simply do not behave like numbers. Abstractly MAX computes
the maximum of a set of numbers just as much as + computes the sum, but
unfortunately we can only represent numbers imperfectly in our computers
∂26-Jul-89 0408 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #169
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89 04:08:41 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA24385; Wed, 26 Jul 89 06:42:22 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17897;
26 Jul 89 0:07 EDT
Date: 26 JUL 89 00:07:12 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #169
To: Scheme@mc.lcs.mit.edu
Reply-To: Scheme@mc.lcs.mit.edu
Message-Id: <8907260007.aa17897@mintaka.lcs.mit.edu>
Scheme Digest #169 26 JUL 89 00:07:12 EDT
Today's Topics:
equal? Bug in PC Scheme
----------------------------------------------------------------------
Date: 25 Jul 89 19:10 GMT+0100
From: Guenther Goerz <goerz@rz.informatik.uni-hamburg.dbp.de>
Message-ID: <44:goerz@rz.informatik.uni-hamburg.dbp.de>
Subject: equal? Bug in PC Scheme
There seems to be a bug in PC Scheme's (ver. 3.03) EQUAL?: If you ask
whether the empty vector equals the empty vector, it says false.
(equal? #() #()) => ()
Vector is the only datatype where this happens.
---Guenther
------------------------------
End of Scheme Digest
********************
∂26-Jul-89 0617 ramsdell@linus.mitre.org INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89 06:17:26 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA25417; Wed, 26 Jul 89 08:59:55 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA27863; Wed, 26 Jul 89 08:55:02 EDT
Posted-Date: Wed, 26 Jul 89 08:54:59 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA01126; Wed, 26 Jul 89 08:55:00 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8907261255.AA01126@huxley.mitre.org>
To: JMiller@crl.enet.dec.com
Cc: rrrs-authors@life.ai.mit.edu
Subject: INF/SUP/MIN/MAX
In-Reply-To: Your message of Fri, 21 Jul 89 09:30:45 -0400.
<8907211330.AA00412@peanut.DEC.COM>
Date: Wed, 26 Jul 89 08:54:59 EDT
I vote for excluding procedures named INF and SUP, and including
procedures named MIN and MAX having the semantics as documented in
R3.95RS. I encourage the editors to add a note describing the
"suprizing" behavior of MIN and MAX.
John
∂26-Jul-89 0745 wand@corwin.ccs.northeastern.edu INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89 07:45:46 PDT
Received: from helios.northeastern.edu by life.ai.mit.edu (4.1/AI-4.10) id AA26157; Wed, 26 Jul 89 10:33:25 EDT
Received: from corwin.ccs.northeastern.edu by helios.northeastern.edu
id aa01420; 26 Jul 89 15:30 EST
Received: by corwin.CCS.Northeastern.EDU (5.51/SMI-3.2+CCS-main-2.6)
id AA00386; Wed, 26 Jul 89 10:00:19 ADT
Date: Wed, 26 Jul 89 10:00:19 ADT
From: Mitchell Wand <wand@corwin.ccs.northeastern.edu>
Message-Id: <8907261300.AA00386@corwin.CCS.Northeastern.EDU>
To: ramsdell@linus.mitre.org
Cc: JMiller@crl.enet.dec.com, rrrs-authors@life.ai.mit.edu
In-Reply-To: ramsdell@linus.mitre.org's message of Wed, 26 Jul 89 08:54:59 EDT <8907261255.AA01126@huxley.mitre.org>
Subject: INF/SUP/MIN/MAX
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Posted-Date: Wed, 26 Jul 89 08:54:59 EDT
From: ramsdell@linus.mitre.org
To: JMiller@crl.enet.dec.com
Cc: rrrs-authors@life.ai.mit.edu
Subject: INF/SUP/MIN/MAX
Date: Wed, 26 Jul 89 08:54:59 EDT
I vote for excluding procedures named INF and SUP, and including
procedures named MIN and MAX having the semantics as documented in
R3.95RS. I encourage the editors to add a note describing the
"suprizing" behavior of MIN and MAX.
John
This is my vote, also. As Alan Bawden said, "inexact numbers just don't
behave like numbers", so all we can do is make the language as consistent as
possible. I don't see that changing the names will help very much, except to
make the language harder to use.
--Mitch
∂26-Jul-89 1103 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89 11:01:41 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA28157; Wed, 26 Jul 89 13:41:27 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24940;
26 Jul 89 13:14 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 13:07:23 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24717;
26 Jul 89 13:00 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27708; Wed, 26 Jul 89 13:00:19 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Wed, 26 Jul 89 12:56:55 edt
Received: from fafnir.think.com by Think.COM; Wed, 26 Jul 89 13:00:30 EDT
Received: from verdi.think.com by fafnir.think.com; Wed, 26 Jul 89 12:58:19 EDT
Received: by verdi.think.com; Wed, 26 Jul 89 12:58:15 EDT
Date: Wed, 26 Jul 89 12:58:15 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907261658.AA07734@verdi.think.com>
To: Alan@reagan.ai.mit.edu
Cc: KMP@stony-brook.scrc.symbolics.com, RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Alan Bawden's message of Wed, 26 Jul 89 01:15 EDT <19890726051514.2.ALAN@PIGPEN.AI.MIT.EDU>
Subject: INF/SUP/MIN/MAX
Date: Wed, 26 Jul 89 01:15 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
... I must say, it's more fun arguing with Steele.
Thank you. I guess.
Most "normal people" expect the distributive law to be true too, but with
inexact numbers, it won't necessarily be. In English we can certainly say
that + returns "the sum" of two numbers, but once inexact numbers are
involved any given Scheme implementation can only claim to compute a
representation of that sum.
(+ 1.0 1e20) ==> 1.0
Having added something non-zero to an inexact 1, should I be concerned that
the result is EQV? to the argument? My mom would probably complain that
the answer should be -different-, yet here Scheme might even return
something that is EQ?.
Hm. My mom might complain about this one too. Maybe you meant "1e-20"?
Or else you got ripped off if you paid more than $2 for that implementation.
Suppose I was planning on feeding this result to
MEMBER? or ASSOC? -- isn't this just as bad as what MAX does?
No, it isn't, Alan, and here's why. Your example takes what we might expect
to be two things and makes them one. This happens all the time in real life.
The morning star turns out to be the evening star also. Your mom turns out to
be the one who makes those yummy chocolate-chip cookies that are sold
nation-wide. Your car turns out to be eqv? to your cdr. You have two pennies
and put one on the railroad track, and the other one gets squished. [This
last example does not outrage intuition if pointers are used: "Last week I
heard that Weinreb had acquired a rare 1903 Quux-head penny. Yesterday at the
party Steele was showing off a penny just like it, and he put it on the
railroad track and it got squished. Today I asked Weinreb if I could see his
penny, and he sadly showed me that it had been squished." This story rendered
into Scheme is:
(penny? Weinreb) => #t
(set! Steele (+ Weinreb 1e-20))
(penny? Steele) => #t
(squish Steele)
(squished? Weinreb) => #t
] You thought + would give you a different number, but because of
machine limitations it gave you the same one back.
It is a much more egregious error to take what you thought you knew to be
one object and make it two. You thought there was only one Venus, but it
turns out that in August it takes a vacation and some asteroid fills in for
a month. You discover that your mom has a twin sister who baked all the
chocolate-chip cookies you used to love when you were a kid (and all these
years you just thought she was absent-minded when she was baking!). Your
car turns out not to be eqv? to your car. Weinreb and Steele jointly
invest in a rare Quux-head penny; then Weinreb tells his insurance company
that his penny got squished, while Steele sells his, in mint condition, to
a collector.
Discovering that two objects are really one is a lot of what computation is
all about: it means you have discovered an interesting cycle in a graph of
relationships. But discovering that one object is really two is a subversion
of naming and the entire notion of object identity. This is why people get
upset over MAX not returning one of its arguments. Suppose you took bids from
three carpenters and asked me to select the best one, and I replied that the
best of the three was some fourth carpenter you never heard of. Yes, his bid
and reputation are, as close as one can tell, at least as good as the best
actually submitted, but such shenanigans would be enough to get me thrown out
of public office. (That's what I get for accepting bids from inexact carpenters.)
--Guy
P.S. Isn't it nice to be arguing this issue on clear-cut technical grounds
instead of just flaming away at each other? :-)
∂26-Jul-89 1119 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89 11:19:16 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA28320; Wed, 26 Jul 89 13:52:08 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25417;
26 Jul 89 13:38 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 13:38:15 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa25407;
26 Jul 89 13:36 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA28048; Wed, 26 Jul 89 13:36:31 EDT
Received: from localhost by zurich.ai.mit.edu; Wed, 26 Jul 89 13:33:14 edt
Date: Wed, 26 Jul 89 13:33:14 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907261733.AA22254@zurich.ai.mit.edu>
To: Alan@reagan.ai.mit.edu
Cc: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Alan Bawden's message of Wed, 26 Jul 89 01:15 EDT <19890726051514.2.ALAN@PIGPEN.AI.MIT.EDU>
Subject: INF/SUP/MIN/MAX
Date: Wed, 26 Jul 89 01:15 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Date: Tue, 25 Jul 89 19:06 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
...
In my opinion, the whole INF/SUP debate comes down to a haughty
disregard on the part of some designers for a clearly expressed need on
the part of users.
I don't see anybody else here defending this point of view, so it must be
me who is being "haughty". Below, I apparently become "anal" and
"stubborn". I must say, it's more fun arguing with Steele.
Just for the record, so far I agree with you Alan. I've been
following the discussion but haven't said anything because I felt you
have been making arguments at least as good as any I could.
∂26-Jul-89 1122 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com INF/SUP/MIN/MAX follow-up
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89 11:21:43 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA28238; Wed, 26 Jul 89 13:45:03 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24989;
26 Jul 89 13:15 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 13:13:48 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24778;
26 Jul 89 13:07 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27775; Wed, 26 Jul 89 13:07:28 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Wed, 26 Jul 89 13:04:15 edt
Received: from fafnir.think.com by Think.COM; Wed, 26 Jul 89 13:07:52 EDT
Received: from verdi.think.com by fafnir.think.com; Wed, 26 Jul 89 13:05:37 EDT
Received: by verdi.think.com; Wed, 26 Jul 89 13:05:35 EDT
Date: Wed, 26 Jul 89 13:05:35 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907261705.AA08756@verdi.think.com>
To: Alan@reagan.ai.mit.edu
Cc: KMP@stony-brook.scrc.symbolics.com, RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Alan Bawden's message of Wed, 26 Jul 89 01:15 EDT <19890726051514.2.ALAN@PIGPEN.AI.MIT.EDU>
Subject: INF/SUP/MIN/MAX follow-up
Warning: serious message follows. :-|
Actually, the remark that "inexact numbers just't don't behave like numbers"
prompts me to ask "are inexact numbers expected to behave like objects"?
Maybe inexact numbers should be totally excused from the requirements of object
identity. (They don't know just who they are, so why should anyone else?)
This also provides a loophole big enough to drive a pdl-number through.
--Guy
∂26-Jul-89 1215 @mc.lcs.mit.edu,@life.ai.mit.edu:KMP@stony-brook.scrc.symbolics.com INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89 12:13:56 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA29060; Wed, 26 Jul 89 14:54:40 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26105;
26 Jul 89 14:48 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 14:48:08 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa26031;
26 Jul 89 14:41 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA28880; Wed, 26 Jul 89 14:40:57 EDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (stony-brook.scrc.symbolics.com) by zurich.ai.mit.edu; Wed, 26 Jul 89 14:37:43 edt
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 631902; 26 Jul 89 14:41:59 EDT
Date: Wed, 26 Jul 89 14:41 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: INF/SUP/MIN/MAX
To: Alan@reagan.ai.mit.edu
Cc: KMP@stony-brook.scrc.symbolics.com, RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: <19890726051514.2.ALAN@PIGPEN.AI.MIT.EDU>
Message-Id: <19890726184151.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Wed, 26 Jul 89 01:15 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
I've never heard users asking for the notion of exactness/inexactness at
all. Ask them what they want, and they will probably tell you that they
want IEEE floating point. As I have said before, I think it would be 100%
reasonable for Scheme to do what every other language does, and adopt some
reasonable set of rules for the behavior of floating point. Unfortunately,
Scheme decided to go in a different direction. Inexact numbers are not
just another name for floating point, so we have -already- decided to give
users something other than what they would ask for. What we are arguing
about here, are the -consequences- of that decision for the function MIN.
I was under the impression that the consistency of the language mattered,
not just what the users think they want before you have a chance to explain
the issues to them.
Well, it's funny because I agree with you on the language design
consistency issue, so I guess the fact I still feel bugged by this
issue exposes the fact that I really think that the decision of Scheme
(an otherwise serious language) to go with this baroque (albeit
mathematically elegant) theory of numbers is like asking the computer
community not to take it seriously. It would be one thing if it -also-
provided floats, so that people could get real work done while they
waited for the other stuff to get field tested, but my own cynical
viewpoint is that--for quite a while yet, anyway-- implementations are
likely to be either correct or efficient, but not both. At least with
floats the fact that games are being played is above board, and you
don't have to fail to conform in order to use standard hardware.
It reminds me of something I saw in the MGLA (Massachusetts General Law
Annotated) about stop light laws. It goes into elaborate detail about
how a city should compute how long a red light should be and it's
careful to point out that if you make the light too long, you encourage
disrespect for the law. I think the point about inconvenience breeding
disrespect is an important one: We have created a theory of numbers so
strange that it's likely that a noticeable fraction of would-be
implementors will implement all of the spec except for numbers. That's
a shame because it encourages the idea that it's ok to deviate from the
spec. I'd personally rather see something that people could implement
usefully, efficiently, straightforwardly and adhere so that there could
be lots of sparklingly conforming implementations. If there's one
thing we've learned from Common Lisp --for whatever you may think of
the particular `semantics' it has--it's that there's tremendous value
in just having agreed on something and made it widely available.
I would also go farther and say that these days I am starting to
believe that what is more important than language standards is datatype
standards. We always speak as if the different languages are just
different syntaxes for saying essentially the same thing. That is,
whether I choose to write FORTRAN
X=A*B
or Lisp
(SETQ X (* A B))
is really an issue of my preferred syntax. But if the primitive
operators themselves compute differing quantities, or if the data types
being passed around do not have a common significance to the different
languages, then the choice of language has an unreasonably elevated
importance because it brings with it an entire philosophy that the
other language much match up to, or must simulate. Someone needs to
start agreeing on a common set of interchange terminology for two
languages to talk to one another. I see most other languages involved
in trying to be able to talk to one another. But I see Scheme crawling
into a corner and refusing to acknowledge the metaphors that those
other languages have chosen. I am not sure this is a good thing.
I agree that advancement must always involve some degree of going
against the grain, but perhaps what I'm saying is that the world is not
exactly knocking at the door of the Scheme community asking where it
should go next. If Scheme wants to affect what is going on, its users
need to start to offer some success stories about what you can do with
its stylized view of numbers that you can't do with `ordinary' numbers,
and start to convince other communities that this is worth paying
attention to. For example, I think that Scheme has credibly done with
`continuations' -- not everyone thinks that first class continuations
are the right thing for every language (some don't even think they're
right for Scheme) but no one can deny that they are -seriously-
interesting, and have led to interesting successes/insights that might
not have been gotten via other means. If Scheme numbers are to persist
in their current form, I would like to be able to speak as confidently
about their demonstrated usefulness, and I don't now feel that I have
the ammunition to do so.
... I must say, it's more fun arguing with Steele.
Good of you to point this out. I'll have to make a point of keeping him
in my camp on arguments so he can guest host my disputes with you when
my overnight ratings start to dip and my sponsors are getting nervous
about me.
Seriously though, I apologize if I seemed a little on the accusing side.
But I am able to contribute precious little time to the Scheme community
these days--much less than I'd like to anyway. So it was more important
to me to make my opinions apparent than to spend a lot of time figuring
out how to present them in the most palatable light.
I certainly didn't mean that anyone should take what I had to say
personally, but I do stand by my overall sense that the Scheme community
spends is traditionally so far to the `right' (language design
politics-wise) that it risks alienating a fair fraction of the tiny
little part of the marketplace (i'm thinking usage-wise, not money-wise,
btw) that is likely to have otherwise appealed to.
T did this in its early days, too, by the way, and while there was clearly
some good effects of that, there have also been good effects due to just
catering to the expressed wants of the actual users.
∂26-Jul-89 1334 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89 13:34:01 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00185; Wed, 26 Jul 89 16:13:37 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26967;
26 Jul 89 15:58 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 15:58:30 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa26908;
26 Jul 89 15:53 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA29807; Wed, 26 Jul 89 15:52:46 EDT
Received: from localhost by zurich.ai.mit.edu; Wed, 26 Jul 89 15:49:33 edt
Date: Wed, 26 Jul 89 15:49:33 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907261949.AA22282@zurich.ai.mit.edu>
To: gls@think.com
Cc: Alan@reagan.ai.mit.edu, KMP@stony-brook.scrc.symbolics.com,
RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Guy Steele's message of Wed, 26 Jul 89 12:58:15 EDT <8907261658.AA07734@verdi.think.com>
Subject: INF/SUP/MIN/MAX
Date: Wed, 26 Jul 89 12:58:15 EDT
From: Guy Steele <gls@think.com>
Suppose I was planning on feeding this result to
MEMBER? or ASSOC? -- isn't this just as bad as what MAX does?
No, it isn't, Alan, and here's why. Your example takes what we might expect
to be two things and makes them one. This happens all the time in real life.
The morning star turns out to be the evening star also. Your mom turns out to
be the one who makes those yummy chocolate-chip cookies that are sold
nation-wide. Your car turns out to be eqv? to your cdr. You have two pennies
and put one on the railroad track, and the other one gets squished. [This
last example does not outrage intuition if pointers are used: "Last week I
heard that Weinreb had acquired a rare 1903 Quux-head penny. Yesterday at the
party Steele was showing off a penny just like it, and he put it on the
railroad track and it got squished. Today I asked Weinreb if I could see his
penny, and he sadly showed me that it had been squished." This story rendered
into Scheme is:
(penny? Weinreb) => #t
(set! Steele (+ Weinreb 1e-20))
(penny? Steele) => #t
(squish Steele)
(squished? Weinreb) => #t
] You thought + would give you a different number, but because of
machine limitations it gave you the same one back.
It is a much more egregious error to take what you thought you knew to be
one object and make it two. You thought there was only one Venus, but it
turns out that in August it takes a vacation and some asteroid fills in for
a month. You discover that your mom has a twin sister who baked all the
chocolate-chip cookies you used to love when you were a kid (and all these
years you just thought she was absent-minded when she was baking!). Your
car turns out not to be eqv? to your car. Weinreb and Steele jointly
invest in a rare Quux-head penny; then Weinreb tells his insurance company
that his penny got squished, while Steele sells his, in mint condition, to
a collector.
Discovering that two objects are really one is a lot of what computation is
all about: it means you have discovered an interesting cycle in a graph of
relationships. But discovering that one object is really two is a subversion
of naming and the entire notion of object identity. This is why people get
upset over MAX not returning one of its arguments. Suppose you took bids from
three carpenters and asked me to select the best one, and I replied that the
best of the three was some fourth carpenter you never heard of. Yes, his bid
and reputation are, as close as one can tell, at least as good as the best
actually submitted, but such shenanigans would be enough to get me thrown out
of public office. (That's what I get for accepting bids from inexact carpenters.)
--Guy
P.S. Isn't it nice to be arguing this issue on clear-cut technical grounds
instead of just flaming away at each other? :-)
I don't buy these arguments: many of them have to do with side
effects, and since when are there any side effects on numbers? So
they don't apply.
The rest, such as whether or not your car is eqv? to your car, don't
seem to contribute much to the discussion, except their obvious
entertainment value. Perhaps I'm making a mistake in taking any part
of your message seriously.
Maybe the problem isn't the action of max or min, but eqv? If we
considered equality as defined by = this question wouldn't come up.
Maybe eqv? is making too fine a distinction.
∂26-Jul-89 1405 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89 14:04:50 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00594; Wed, 26 Jul 89 16:46:21 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27244;
26 Jul 89 16:31 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 16:31:31 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa27180;
26 Jul 89 16:26 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00258; Wed, 26 Jul 89 16:26:14 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Wed, 26 Jul 89 16:23:01 edt
Received: from fafnir.think.com by Think.COM; Wed, 26 Jul 89 16:26:42 EDT
Received: from verdi.think.com by fafnir.think.com; Wed, 26 Jul 89 16:24:27 EDT
Received: by verdi.think.com; Wed, 26 Jul 89 16:24:25 EDT
Date: Wed, 26 Jul 89 16:24:25 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907262024.AA06827@verdi.think.com>
To: cph@zurich.ai.mit.edu
Cc: gls@think.com, Alan@reagan.ai.mit.edu, KMP@stony-brook.scrc.symbolics.com,
RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Chris Hanson's message of Wed, 26 Jul 89 15:49:33 edt <8907261949.AA22282@zurich.ai.mit.edu>
Subject: INF/SUP/MIN/MAX
Date: Wed, 26 Jul 89 15:49:33 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Date: Wed, 26 Jul 89 12:58:15 EDT
From: Guy Steele <gls@think.com>
Suppose I was planning on feeding this result to
MEMBER? or ASSOC? -- isn't this just as bad as what MAX does?
No, it isn't, Alan, and here's why. Your example takes what we might expect
to be two things and makes them one. This happens all the time in real life.
The morning star turns out to be the evening star also. Your mom turns out to
be the one who makes those yummy chocolate-chip cookies that are sold
nation-wide. Your car turns out to be eqv? to your cdr. You have two pennies
and put one on the railroad track, and the other one gets squished. [This
last example does not outrage intuition if pointers are used: "Last week I
heard that Weinreb had acquired a rare 1903 Quux-head penny. Yesterday at the
party Steele was showing off a penny just like it, and he put it on the
railroad track and it got squished. Today I asked Weinreb if I could see his
penny, and he sadly showed me that it had been squished." This story rendered
into Scheme is:
(penny? Weinreb) => #t
(set! Steele (+ Weinreb 1e-20))
(penny? Steele) => #t
(squish Steele)
(squished? Weinreb) => #t
] You thought + would give you a different number, but because of
machine limitations it gave you the same one back.
It is a much more egregious error to take what you thought you knew to be
one object and make it two. You thought there was only one Venus, but it
turns out that in August it takes a vacation and some asteroid fills in for
a month. You discover that your mom has a twin sister who baked all the
chocolate-chip cookies you used to love when you were a kid (and all these
years you just thought she was absent-minded when she was baking!). Your
car turns out not to be eqv? to your car. Weinreb and Steele jointly
invest in a rare Quux-head penny; then Weinreb tells his insurance company
that his penny got squished, while Steele sells his, in mint condition, to
a collector.
Discovering that two objects are really one is a lot of what computation is
all about: it means you have discovered an interesting cycle in a graph of
relationships. But discovering that one object is really two is a subversion
of naming and the entire notion of object identity. This is why people get
upset over MAX not returning one of its arguments. Suppose you took bids from
three carpenters and asked me to select the best one, and I replied that the
best of the three was some fourth carpenter you never heard of. Yes, his bid
and reputation are, as close as one can tell, at least as good as the best
actually submitted, but such shenanigans would be enough to get me thrown out
of public office. (That's what I get for accepting bids from inexact carpenters.)
--Guy
P.S. Isn't it nice to be arguing this issue on clear-cut technical grounds
instead of just flaming away at each other? :-)
I don't buy these arguments: many of them have to do with side
effects, and since when are there any side effects on numbers? So
they don't apply.
Granted. "Plus ca change, plus c'est la meme chose", as Sussman and I
quoted in "The Art of the Interpreter". The more things change, the more
they remain the same; that is, the notion of object identity may be linked
to the notion of side effect. And yet, if numbers are not subject to
side effects, in what sense can we say that 1 = 1, or that 1 /= 2 ?
I think that when we say 1 = 1, we are temporarily entertaining the
possibility that the two instances of "1" represent *different* things,
precisely so that we may then make the assertion that they are the same
after all. If one of the 1's were not 1 after all, then things would be
different, including the truth of the equality. This subjunctive
hypothesis amounts to a side effect, for we are considering, hypothetically
and however evanescently, a world altered from our own (whether by SETQ
or by adding an entry to the head of an a-list).
The rest, such as whether or not your car is eqv? to your car, don't
seem to contribute much to the discussion, except their obvious
entertainment value. Perhaps I'm making a mistake in taking any part
of your message seriously.
On the contrary, I am trying (admittedly by entertaining means) to get at
the root of our intuitions about object identity, as I and many of us have
been doing for years now. The entire point is that it is hardly surprising
to discover that (eqv? (car x) (cdr x)) is true; but it is horrifying to
discover that (eqv? (car x) (car x)) is false, and we go scurrying for
possible explanations (a parallel process maybe did a side effect between
the two calls to car ?). The two cases are quite different.
Maybe the problem isn't the action of max or min, but eqv? If we
considered equality as defined by = this question wouldn't come up.
Maybe eqv? is making too fine a distinction.
Indeed, and this is essentially the subject of the message I sent
after this one (the one you replied to): maybe inexact numbers
should not possess object identity. Please take this seriously.
(Maybe it's the wrong idea, but it's not a frivolous idea, I think.)
--Guy
∂26-Jul-89 1437 @mc.lcs.mit.edu,@life.ai.mit.edu:gjs@hpesogg.hp.com INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89 14:37:39 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00957; Wed, 26 Jul 89 17:25:05 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27603;
26 Jul 89 17:09 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 17:09:11 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa27573;
26 Jul 89 17:03 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00771; Wed, 26 Jul 89 17:03:19 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Wed, 26 Jul 89 17:00:05 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA11348; Wed, 26 Jul 89 14:02:53 pdt
Message-Id: <8907262102.AA11348@sde.hp.com>
Received: by hpesogg; Wed, 26 Jul 89 14:01:54 pdt
Date: Wed, 26 Jul 89 14:01:54 pdt
From: Gerald Jay Sussman <gjs@hpesogg.hp.com>
To: Alan@reagan.ai.mit.edu
Cc: RRRS-Authors@zurich.ai.mit.edu
Subject: INF/SUP/MIN/MAX
I don't see anybody else here defending this point of view, so it must be
me who is being "haughty". Below, I apparently become "anal" and
"stubborn". I must say, it's more fun arguing with Steele.
Keep up the good work, I keep my mouth shut when I watch a master in
action. And don't let the nasty things some people say get to you.
Steele is indeed fun, we need more of his time!
∂26-Jul-89 1952 @mc.lcs.mit.edu,@life.ai.mit.edu:kempf@sun.com Please Remove
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89 19:52:28 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA03711; Wed, 26 Jul 89 22:37:02 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00828;
26 Jul 89 22:25 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 22:25:32 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa00818;
26 Jul 89 22:22 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03668; Wed, 26 Jul 89 22:22:45 EDT
Received: from Sun.COM ([192.9.9.1]) by zurich.ai.mit.edu; Wed, 26 Jul 89 22:19:32 edt
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
id AA25442; Wed, 26 Jul 89 19:22:26 PDT
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.1)
id AA22947; Wed, 26 Jul 89 12:46:45 PDT
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA01346; Wed, 26 Jul 89 12:47:25 PDT
Message-Id: <8907261947.AA01346@suntana.sun.com>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Please Remove
Date: Wed, 26 Jul 89 12:47:23 PDT
From: kempf@sun.com
I tried rrrs-authors-request, but that didn't work, so, risking flamage,
here is a request to remove me from this list. Thanx.
jak
∂27-Jul-89 0855 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Jul 89 08:54:51 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA09751; Thu, 27 Jul 89 11:31:55 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09635;
27 Jul 89 11:26 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jul 89 11:26:41 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09599;
27 Jul 89 11:20 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA09544; Thu, 27 Jul 89 11:20:02 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Thu, 27 Jul 89 11:16:45 edt
Received: from fafnir.think.com by Think.COM; Thu, 27 Jul 89 11:19:39 EDT
Received: from verdi.think.com by fafnir.think.com; Thu, 27 Jul 89 11:17:23 EDT
Received: by verdi.think.com; Thu, 27 Jul 89 11:17:20 EDT
Date: Thu, 27 Jul 89 11:17:20 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907271517.AA11786@verdi.think.com>
To: wand@corwin.ccs.northeastern.edu
Cc: gls@think.com, cph@zurich.ai.mit.edu, gls@think.com,
Alan@reagan.ai.mit.edu, KMP@stony-brook.scrc.symbolics.com,
RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Mitchell Wand's message of Thu, 27 Jul 89 09:30:53 ADT <8907271230.AA08188@corwin.CCS.Northeastern.EDU>
Subject: INF/SUP/MIN/MAX
Date: Thu, 27 Jul 89 09:30:53 ADT
From: Mitchell Wand <wand@corwin.ccs.northeastern.edu>
Date: Wed, 26 Jul 89 16:24:25 EDT
From: Guy Steele <gls@think.com>
Date: Wed, 26 Jul 89 15:49:33 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
...
I don't buy these arguments: many of them have to do with side
effects, and since when are there any side effects on numbers? So
they don't apply.
Granted. "Plus ca change, plus c'est la meme chose", as Sussman and I
quoted in "The Art of the Interpreter". The more things change, the more
they remain the same; that is, the notion of object identity may be linked
to the notion of side effect. And yet, if numbers are not subject to
side effects, in what sense can we say that 1 = 1, or that 1 /= 2 ?
I think that when we say 1 = 1, we are temporarily entertaining the
possibility that the two instances of "1" represent *different* things,
precisely so that we may then make the assertion that they are the same
after all. If one of the 1's were not 1 after all, then things would be
different, including the truth of the equality. This subjunctive
hypothesis amounts to a side effect, for we are considering, hypothetically
and however evanescently, a world altered from our own (whether by SETQ
or by adding an entry to the head of an a-list).
I'm not convinced by this argument. While it is surely true that object
identity is linked to the notion of side-effect, it does not follow that the
truth or falsity of the proposition "1=1" has some subjunctive hypothesis that
amounts to a side effect. If there were a subjunctive hypothesis in "1=1", it
would range over the class of propositions, ie those questions of the form
`M = N', as M and N range over some class of expressions. The proposition
asks whether M and N denote the same thing. So "1 = 1" is true, but "1 = 2"
is false.
Let me recapitulate the form of my entire argument. I claimed:
A property that many programmers expect of MAX is that
if (MAX a b c ...) => x then x=a or x=b or x=c or ...
where I use infix "=" to mean object identity. I complained
that the MAX in R3.95 fails to have this property.
Alan then compared this situation to that of +, remarking that
+ also fails, by returning something the same as an argument
when you expected it to be different.
I then countered that these were two different types of failure:
MAX fails to preserve object identity (given that one's model
of its behavior or implementation is that it ought to), whereas
+ fails to preserve object distinctness (given that a model
of the algebraic properties of + says they ought to be distinct.
Chris then objected that many of my informal examples revolved around the
notion of side effect, but because numbers as such are not subject to side
effects in Scheme those arguments were therefore irrelevant.
My reply was an attempt to restate my point about object identity
more clearly, but it is hard to discuss object identity without
dragging in side effects to some extent.
The failure of + to preserve object distinctness--that is, the failure
to obey the law
if x /= 0 then x+y /= x
may be regarded as a bad definition or implementation of +.
On the other hand, a failure to preserve object identity in MAX,
while it may also be regarded as a bad definition or implementation
of MAX, also looks suspiciously like a breakdown of the naming or
equality mechanisms in the language, and is therefore much more disturbing.
I believe that "1 = 1" does entail a subjunctive hypothesis at some
stage if its interpretation process, because I regard the mark "1"
on the paper as a numeral and not a number; it's just another name,
one I have agreed not to alter capriciously most of the time.
(But you know what I mean when I say "He has fourteen cats--for some
value of fourteen.") Until I have interpreted that mark and evaluated
it to the Platonic number one, there is the possibility that the
equality fails to hold. Or I could regard the equality algebraically
instead of numerically, noting that the two sides are symbolically
identical; but then in deducing the truth of the equality I assume
that no side effect would take place during the hypothetical eventual
evaluation of the expressions. It is not so much, I guess, that
the hypothesis *is* a side effect, as that it temporarily entertains
the possibility that one might occur.
--Guy
∂27-Jul-89 1106 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com INF/SUP/MIN/MAX and correct use of time
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Jul 89 11:05:58 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA11699; Thu, 27 Jul 89 13:50:57 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09793;
27 Jul 89 11:33 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jul 89 11:33:15 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09622;
27 Jul 89 11:24 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA09615; Thu, 27 Jul 89 11:24:50 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Thu, 27 Jul 89 10:33:47 edt
Received: from fafnir.think.com by Think.COM; Thu, 27 Jul 89 10:35:49 EDT
Received: from verdi.think.com by fafnir.think.com; Thu, 27 Jul 89 10:33:30 EDT
Received: by verdi.think.com; Thu, 27 Jul 89 10:33:25 EDT
Date: Thu, 27 Jul 89 10:33:25 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907271433.AA07821@verdi.think.com>
To: gjs@hpesogg.hp.com
Cc: Alan@reagan.ai.mit.edu, RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Gerald Jay Sussman's message of Wed, 26 Jul 89 14:01:54 pdt <8907262102.AA11348@sde.hp.com>
Subject: INF/SUP/MIN/MAX and correct use of time
Date: Wed, 26 Jul 89 14:01:54 pdt
From: Gerald Jay Sussman <gjs@hpesogg.hp.com>
I don't see anybody else here defending this point of view, so it must be
me who is being "haughty". Below, I apparently become "anal" and
"stubborn". I must say, it's more fun arguing with Steele.
Keep up the good work, I keep my mouth shut when I watch a master in
action. And don't let the nasty things some people say get to you.
Steele is indeed fun, we need more of his time!
Lest anyone think Alan and I have become bitter adversaries,
or that we are not spending our time appropriately, let me report
(forgive me, Alan) that we coincidentally ended up at the same
movie showing yesterday afternoon and when we met we grinned
at each other and shook hands. We know how to spend our time.
Incidentally, "The Brave Little Toaster" is pretty fair animation, great
storytelling for the age level it is nominally pitched at, good
characterization (given that the heroes are household appliances), and has
some fine parody sequences for us so-called grown-ups. (Maybe Alan will
have some differing opinion, and we can discuss *that* for a while. :-)
∂27-Jul-89 1116 @mc.lcs.mit.edu,@life.ai.mit.edu:wand@corwin.ccs.northeastern.edu INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Jul 89 11:16:38 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA11722; Thu, 27 Jul 89 13:52:26 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09801;
27 Jul 89 11:34 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jul 89 11:33:41 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09627;
27 Jul 89 11:26 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA09628; Thu, 27 Jul 89 11:25:28 EDT
Received: from helios.northeastern.edu (helios.northeastern.edu) by zurich.ai.mit.edu; Thu, 27 Jul 89 10:02:21 edt
Received: from corwin.ccs.northeastern.edu by helios.northeastern.edu
id aa17480; 27 Jul 89 15:00 EST
Received: by corwin.CCS.Northeastern.EDU (5.51/SMI-3.2+CCS-main-2.6)
id AA08188; Thu, 27 Jul 89 09:30:53 ADT
Date: Thu, 27 Jul 89 09:30:53 ADT
From: Mitchell Wand <wand@corwin.ccs.northeastern.edu>
Message-Id: <8907271230.AA08188@corwin.CCS.Northeastern.EDU>
To: gls@think.com
Cc: cph@zurich.ai.mit.edu, gls@think.com, Alan@reagan.ai.mit.edu,
KMP@stony-brook.scrc.symbolics.com, RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Guy Steele's message of Wed, 26 Jul 89 16:24:25 EDT <8907262024.AA06827@verdi.think.com>
Subject: INF/SUP/MIN/MAX
[Just to make sure that everyone's archive's continue to grow quadratically, I
will follow the usual protocol of inserting an indented copy of the
correspondence up to this point.]
Date: Wed, 26 Jul 89 16:24:25 EDT
From: Guy Steele <gls@think.com>
To: cph@zurich.ai.mit.edu
Cc: gls@think.com, Alan@reagan.ai.mit.edu,
KMP@stony-brook.scrc.symbolics.com, RRRS-Authors@zurich.ai.mit.edu
Subject: INF/SUP/MIN/MAX
Date: Wed, 26 Jul 89 15:49:33 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Date: Wed, 26 Jul 89 12:58:15 EDT
From: Guy Steele <gls@think.com>
Suppose I was planning on feeding this result to
MEMBER? or ASSOC? -- isn't this just as bad as what MAX does?
No, it isn't, Alan, and here's why. Your example takes what we might expect
to be two things and makes them one. This happens all the time in real life.
The morning star turns out to be the evening star also. Your mom turns out to
be the one who makes those yummy chocolate-chip cookies that are sold
nation-wide. Your car turns out to be eqv? to your cdr. You have two pennies
and put one on the railroad track, and the other one gets squished. [This
last example does not outrage intuition if pointers are used: "Last week I
heard that Weinreb had acquired a rare 1903 Quux-head penny. Yesterday at the
party Steele was showing off a penny just like it, and he put it on the
railroad track and it got squished. Today I asked Weinreb if I could see his
penny, and he sadly showed me that it had been squished." This story rendered
into Scheme is:
(penny? Weinreb) => #t
(set! Steele (+ Weinreb 1e-20))
(penny? Steele) => #t
(squish Steele)
(squished? Weinreb) => #t
] You thought + would give you a different number, but because of
machine limitations it gave you the same one back.
It is a much more egregious error to take what you thought you knew to be
one object and make it two. You thought there was only one Venus, but it
turns out that in August it takes a vacation and some asteroid fills in for
a month. You discover that your mom has a twin sister who baked all the
chocolate-chip cookies you used to love when you were a kid (and all these
years you just thought she was absent-minded when she was baking!). Your
car turns out not to be eqv? to your car. Weinreb and Steele jointly
invest in a rare Quux-head penny; then Weinreb tells his insurance company
that his penny got squished, while Steele sells his, in mint condition, to
a collector.
Discovering that two objects are really one is a lot of what computation is
all about: it means you have discovered an interesting cycle in a graph of
relationships. But discovering that one object is really two is a subversion
of naming and the entire notion of object identity. This is why people get
upset over MAX not returning one of its arguments. Suppose you took bids from
three carpenters and asked me to select the best one, and I replied that the
best of the three was some fourth carpenter you never heard of. Yes, his bid
and reputation are, as close as one can tell, at least as good as the best
actually submitted, but such shenanigans would be enough to get me thrown out
of public office. (That's what I get for accepting bids from inexact carpenters.)
--Guy
P.S. Isn't it nice to be arguing this issue on clear-cut technical grounds
instead of just flaming away at each other? :-)
I don't buy these arguments: many of them have to do with side
effects, and since when are there any side effects on numbers? So
they don't apply.
Granted. "Plus ca change, plus c'est la meme chose", as Sussman and I
quoted in "The Art of the Interpreter". The more things change, the more
they remain the same; that is, the notion of object identity may be linked
to the notion of side effect. And yet, if numbers are not subject to
side effects, in what sense can we say that 1 = 1, or that 1 /= 2 ?
I think that when we say 1 = 1, we are temporarily entertaining the
possibility that the two instances of "1" represent *different* things,
precisely so that we may then make the assertion that they are the same
after all. If one of the 1's were not 1 after all, then things would be
different, including the truth of the equality. This subjunctive
hypothesis amounts to a side effect, for we are considering, hypothetically
and however evanescently, a world altered from our own (whether by SETQ
or by adding an entry to the head of an a-list).
I'm not convinced by this argument. While it is surely true that object
identity is linked to the notion of side-effect, it does not follow that the
truth or falsity of the proposition "1=1" has some subjunctive hypothesis that
amounts to a side effect. If there were a subjunctive hypothesis in "1=1", it
would range over the class of propositions, ie those questions of the form
`M = N', as M and N range over some class of expressions. The proposition
asks whether M and N denote the same thing. So "1 = 1" is true, but "1 = 2"
is false. If we embed these in a programming language, then we can get
confused in two ways:
1. The value denoted by the expression M may be implementation-dependent.
Therefore the truth or falsity of "M = N" may be implementation-dependent.
2. The computation of M and N may cause side-effects which change the objects
that M and N compute. Thus (eqv? (car x) (car x)) may fail because there is
some parallel process interfering with the calculation.
It seems to me that (1) is the major source of problems here, because we have
been very careful to NOT completely specify the semantics of numbers (exact OR
inexact). Unless we want to go the whole way and talk about "inexact
booleans" (which I do not recommend), at some point we have to make a cut and
admit implementation-dependence rather than inexactness. [My guess is that
we've done a pretty good job of choosing where to make this cut, judging by
the arcana in the discussion so far]. We probably shouldn't get distracted by
(2), which seems largely independent.
The rest, such as whether or not your car is eqv? to your car, don't
seem to contribute much to the discussion, except their obvious
entertainment value. Perhaps I'm making a mistake in taking any part
of your message seriously.
On the contrary, I am trying (admittedly by entertaining means) to get at
the root of our intuitions about object identity, as I and many of us have
been doing for years now. The entire point is that it is hardly surprising
to discover that (eqv? (car x) (cdr x)) is true; but it is horrifying to
discover that (eqv? (car x) (car x)) is false, and we go scurrying for
possible explanations (a parallel process maybe did a side effect between
the two calls to car ?). The two cases are quite different.
Maybe the problem isn't the action of max or min, but eqv? If we
considered equality as defined by = this question wouldn't come up.
Maybe eqv? is making too fine a distinction.
Indeed, and this is essentially the subject of the message I sent
after this one (the one you replied to): maybe inexact numbers
should not possess object identity. Please take this seriously.
(Maybe it's the wrong idea, but it's not a frivolous idea, I think.)
--Guy
--Mitch
∂27-Jul-89 1122 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@mrloog.la.tek.com Re: Regularization of apply (long)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Jul 89 11:22:19 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA11909; Thu, 27 Jul 89 14:06:16 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa10786;
27 Jul 89 12:49 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jul 89 12:49:06 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa10746;
27 Jul 89 12:44 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA10663; Thu, 27 Jul 89 12:44:05 EDT
Received: from RELAY.CS.NET (relay.cs.net) by zurich.ai.mit.edu; Thu, 27 Jul 89 12:40:49 edt
Received: from tektronix.tek.com by RELAY.CS.NET id aa03574; 27 Jul 89 12:40 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA05947; Thu, 27 Jul 89 09:41:35 PDT
Received: by dadla.LA.TEK.COM (5.51/6.24)
id AA06439; Thu, 27 Jul 89 09:22:54 PDT
Received: by mrloog.la.tek.com (1.2/7.1)
id AA08823; Thu, 27 Jul 89 09:27:42 pdt
Message-Id: <8907271627.AA08823@mrloog.la.tek.com>
To: jinx%hpesogg@sde.hp.com
Cc: rrrs-authors@zurich.ai.mit.edu, Scheme-Standard@wheaties.ai.mit.edu,
gls@think.com
Subject: Re: Regularization of apply (long)
Date: 27 Jul 89 09:27:35 PDT (Thu)
From: kend%mrloog.la.tek.com@relay.cs.net
>[Ken Dickey]
> I would prefer that APPLY be applicable only to multiple values. For
> that matter, I favor multiple value rest arguments--dropping rest *lists*
> altogether.
>[Jinx]
>What do you mean by multiple values?
>Do you mean something like LAMBDA*'s & pseudo-objects?
>If you mean something along the more traditional lines, you have just
>pushed the problem one level deeper, since your multiple value
>receivers are also expressed in lambda notation and therefore you need
>to have dotted lists.
Yes, I will say it. I like LAMBDA* [with some restrictions: single-value
assignments only, single rest argument, I prefer VALUES to #\& for multiple
value returns]. I use T's RETURN/RECEIVE and find multiple values quite
handy. LAMBDA* provides a convenient way to bind/spread multiple values.
There it is, out of the closet.
I happen to think that LAMBDA* can be compiled to add significant
performance (over rest lists), particularly in the presence of early
binding. I happen to be working in an environment where this matters
(semi-realtime embedded systems). Having the user do a case dispatch on
the number of arguments (particularly using rest lists) usually looses in
the speed department. I also think that errors are fewer when the
compiler can check them--and possibly optimize away the checks.
Your coroutines are pretty neat, but don't help me out much for
variable-arity proceedures.
(define PPRINT
(lambda*
[(<value> <port> <line-length>)
(%pprint <value> <port> <line-length>)]
[(<value> <port>)
(%pprint <value> <port> default-line-length)]
[(<value>)
(%pprint <value> (standard-output) default-line-length)]
) )
I know that you can construct code to handle such cases, but question
whether this can be compiled as efficently (given comparitive
implementation effort). Personally, I would rather have the
opportunities for optimization using multiple values and lambda* because
I think that we could do some really winning code generation.
-Ken Dickey kend@mrloog.LA.TEK.COM
∂27-Jul-89 1209 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu Multiple Values for R5RS (VERY LONG)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Jul 89 12:09:40 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA12542; Thu, 27 Jul 89 14:54:42 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12121;
27 Jul 89 14:37 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jul 89 14:33:38 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa11974;
27 Jul 89 14:28 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA12213; Thu, 27 Jul 89 14:27:08 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Thu, 27 Jul 89 14:23:39 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA08835; Thu, 27 Jul 89 11:26:00 PDT
Date: Thu, 27 Jul 89 11:26:00 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907271826.AA08835@sesame.Stanford.EDU>
To: RRRS-Authors@zurich.ai.mit.edu
Subject: Multiple Values for R5RS (VERY LONG)
The following proposal is for R5RS ****NOT**** R4RS.
It is our impression that the discussions at Snowbird on multiple values
broke down mostly due to misunderstandings. At this time, we would like to
make a proposal which we feel addresses all of the concerns expressed during
those and subsequent discussions. We would appreciate responses to this
proposal, both pro and con, so as to ensure continued discussion of this
issue, and its eventual (we hope) resolution.
This proposal contains the following components:
1. A description of the introduced procedures.
2. A discussion of a number of the design decisions.
3. A presentation of several 'higher' level constructs which can be
built using the introduced primitives.
Our proposal calls for the introduction of three new procedures, only one of
which does not have a naive implementation in R4RS. The functions and their
semantics are as follows (we suggest these names only to protect the
innocent):
(values obj ...) essential procedure
Returns 0 or more values to an accepting form.
(values) => returns zero (no) values
(values 1) => returns a single value, 1
(values 1 'a) => returns two values, 1 and the symbol a
(apply-values receiver generator) essential procedure
Applies the procedure 'receiver' to the values generated by thawing the
thunk, 'generator'. The arity of 'receiver' must be compatible with the
return-arity of 'generator' (i.e., the number of values returned by
'generator'). In the absence of a rest argument, the arity of 'receiver'
must be identical to the return-arity of 'generator'. The formals of
'receiver' will be bound to fresh locations and the values returned by
'generator' will be stored in the respective locations. When a rest
argument is present, the return-arity of 'generator' must be greater than or
equal to the number of required arguments to 'receiver'. The required
actuals will be handled as above; the rest argument will be bound to a fresh
location in which a newly created list, composed of the remaining actuals
returned by 'generator', will be stored. It is an error for the arity of
'receiver' and the return-arity of 'generator' to be incompatible. [This
will be discussed later in the proposal.]
(apply-values cons
(lambda ()
(values 1 2))) => (1 . 2)
(arity applicable) essential procedure
The argument to arity must be an applicable object (i.e., objects for which
procedure? returns #t). Arity returns three values: the minimum number of
actuals accepted by 'applicable', the maximum number of actuals accepted by
'applicable' (excluding, if present, a rest argument, and including optional
arguments, for those implementations that support optionals), and a boolean
representing the presence of a rest argument.
(arity car) => 1, 1, #f
(arity +) => 1, 1, #t
In an implementation that supports optional arguments (which we will denote
using &optional)...
(arity (lambda (x &optional y)
<body>)) => 1, 2, #f
(arity (lambda (x &optional y . rest)
<body>)) => 1, 2, #t
(car (call/cc
(lambda (k)
(arity k) ; arity would return 1, 1, #f
<body>)))
(apply-values cons
(lambda ()
(call/cc
(lambda (k)
(arity k) ; arity would return 2, 2, #f
<body>))))
(apply-values (lambda (. args)
<body>)
(lambda ()
(call/cc
(lambda (k)
(arity k) ; arity would return 0, 0, #t
<body>))))
(begin
<expression>
...
(call/cc
(lambda (k)
(arity k) ; arity would return 0, 0, #t
<body>))
...
<expression>)
If a continuation is captured in a tail-recursive position, the
continuation's arity is determined by the accepting stack frame.
(cons <expression>
(begin
<expression>
...
(call/cc
(lambda (k)
(arity k) ; arity would return 1, 1, #f
<body>))))
(apply-values +
(lambda ()
<expression>
...
(call/cc
(lambda (k)
(arity k) ; arity would return 0, 0, #t
<body>))))
A point of contention at Snowbird was the issue of incompatibility of arity
between generators and receivers. In our proposal returning to few values
is an error to maintain symmetry with procedure application. While there
seemed to be virtually universal agreement on the former point, the
appropriate manner of handling the return of more values than expected was
not agreed upon. Based on the following three considerations, we propose
that returning excessive values be considered an error:
1. Currently the application of a procedure to excessive arguments is
an error in RNRS; similarly, multiple value application of a
procedure to too many actuals should also be an error.
2. It is sometimes desirable to create upwardly compatible versions of
procedures by increasing their return-arity. This can be
accomplished through the use of 'call/cc' and 'arity'. For
example, the standard definition of 'quotient' could be extended to
return both the quotient and remainder, as follows:
(define quotient
(let ((original-quotient quotient))
(lambda (n1 n2)
(call/cc ;Capture the implicit continuation
(lambda (k)
(if (apply-values ;If k accepts more than one actual
(lambda (min max rest?)
(or rest?
(>= max 2)))
(lambda ()
(arity k)))
(values (original-quotient n1 n2)
(remainder n1 n2))
(original-quotient n1 n2)))))))
3. Some individuals at Snowbird desired CLtL semantics for the return
of multiple values to a form which expecting a single value (i.e.,
stripping). This functionality can be achieved using a
'first-value' procedure which can be written in standard RNRS.
(define first-value
(lambda (thunk)
(apply-values (lambda (return-me . rest)
return-me)
thunk)))
Further, a generalized values referencing procedure can be defined
as shown below:
(define values-ref
(lambda (thunk n)
(apply-values (lambda (. args)
(list-ref args n))
thunk)))
One of the advantages of this approach is that some programming
errors could be recognized at compile time; otherwise, these errors
would not be detectable until runtime.
NOTES:
1. In our proposal multiple return values are not a first class data type.
2. This proposal does NOT specify the return-arity of the current RNRS
procedures; but, this must be done as part of any eventually agreed upon
semantics for multiple values.
3. We would like (values <arg>) and <arg> to be operationally equivalent.
However in deference to implementors who want to minimize the number of
modifications needed to support multiple values, we have required only one
modification, the addition of the primitive arity. To get the semantics we
desire, it would appear that modification to an implementation's procedure
application mechanism would be required. If implementors are agreeable,
we advise that the above semantics be added to our working proposal.
Procedure application could then be viewed as syntactic sugar for a
multiple values application as shown below:
(f x y ...) = (apply-values f (lambda () (values x y ...)))
alpha
EXTRA FOR EXPERTS:
(define make-values->
(lambda (constructor)
(lambda (thunk)
(apply-values constructor
thunk))))
(define values->vector
(make-values-> vector))
Given a macro package (e.g., Extend Syntax) one can define:
(extend-syntax (multiple-value-let)
((multiple-value-let formals generator body ...)
(apply-values (lambda formals
body ...)
generator)))
(peace chance)
Morry & mas
∂28-Jul-89 1154 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Regularization of apply (long)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Jul 89 11:54:11 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00597; Fri, 28 Jul 89 14:37:17 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16292;
27 Jul 89 19:46 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jul 89 19:46:42 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa16200;
27 Jul 89 19:39 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03289; Thu, 27 Jul 89 19:39:25 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Thu, 27 Jul 89 19:36:13 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA18897; Thu, 27 Jul 89 16:39:07 pdt
Message-Id: <8907272339.AA18897@sde.hp.com>
Received: by hpesogg; Thu, 27 Jul 89 16:38:10 pdt
Date: Thu, 27 Jul 89 16:38:10 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: kend%mrloog.la.tek.com@relay.cs.net
Cc: rrrs-authors@zurich.ai.mit.edu, Scheme-Standard@wheaties.ai.mit.edu,
gls@think.com
In-Reply-To: kend%mrloog.la.tek.com@relay.cs.net's message of 27 Jul 89 09:27:35 PDT (Thu) <8907271627.AA08823@mrloog.la.tek.com>
Subject: Regularization of apply (long)
Reply-To: jinx%hpesogg@sde.hp.com
Your coroutines are pretty neat, but don't help me out much for
variable-arity proceedures.
(define PPRINT
(lambda*
[(<value> <port> <line-length>)
(%pprint <value> <port> <line-length>)]
[(<value> <port>)
(%pprint <value> <port> default-line-length)]
[(<value>)
(%pprint <value> (standard-output) default-line-length)]
) )
I know that you can construct code to handle such cases, but question
whether this can be compiled as efficently (given comparitive
implementation effort). Personally, I would rather have the
opportunities for optimization using multiple values and lambda* because
I think that we could do some really winning code generation.
I'm not advocating the particular details of the code that I
submitted. They were just a hint of what I would like to see.
I also feel quite strongly that the following three issues are
separable. Lambda* jumbles them up, and that is my main problem with
it:
1) Multiple values.
2) Dispatch on variable arity.
3) Acceptance of "unbounded" numbers of arguments.
I think many people agree that the current "dot notation" and apply
have some problems, but I don't think that replacing them with lambda*
solves them. The three issues above are (I think) independent, and
should be solved by independent mechanisms.
A second point is that I don't like special forms when procedures can
do the job, and all the three issues above can be solved as
efficiently by adding procedures as by adding special forms.
Special forms are syntactic cuteness that people who so desire can add
on top. Real men don't use macros :-)
∂28-Jul-89 1219 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Jul 89 12:18:18 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01152; Fri, 28 Jul 89 15:00:58 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16296;
27 Jul 89 19:46 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jul 89 19:46:55 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa16208;
27 Jul 89 19:41 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03324; Thu, 27 Jul 89 19:40:55 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Thu, 27 Jul 89 19:37:42 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA18924; Thu, 27 Jul 89 16:40:34 pdt
Message-Id: <8907272340.AA18924@sde.hp.com>
Received: by hpesogg; Thu, 27 Jul 89 16:39:54 pdt
Date: Thu, 27 Jul 89 16:39:54 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: wand@corwin.ccs.northeastern.edu
Cc: gls@think.com, cph@zurich.ai.mit.edu, gls@think.com,
Alan@reagan.ai.mit.edu, KMP@stony-brook.scrc.symbolics.com,
RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Mitchell Wand's message of Thu, 27 Jul 89 09:30:53 ADT <8907271230.AA08188@corwin.CCS.Northeastern.EDU>
Subject: INF/SUP/MIN/MAX
Reply-To: jinx%hpesogg@sde.hp.com
[Just to make sure that everyone's archive's continue to grow quadratically, I
will follow the usual protocol of inserting an indented copy of the
correspondence up to this point.]
There are two incompatible mail file GC algorithms. :-)
The reason I copy the incoming message is that I get paranoid whenever
my mail file has more than 10 messages, therefore I flush all incoming
message. If messages did not include the message they were answering,
I would be lost, since I could not go back (conveniently) to read the
source of confusion.
∂28-Jul-89 1401 @mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Jul 89 14:01:30 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02863; Fri, 28 Jul 89 16:47:42 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17485;
27 Jul 89 21:16 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 27 Jul 89 21:16:48 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 241995; Thu 27-Jul-89 21:15:30 EDT
Date: Thu, 27 Jul 89 21:15 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Subject: Numbers
To: gls@think.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8907261612.AA01435@verdi.think.com>,
<8907261658.AA07734@verdi.think.com>,
<8907261705.AA08756@verdi.think.com>,
<19890726184151.4.KMP@BOBOLINK.SCRC.Symbolics.COM>,
<8907271433.AA07821@verdi.think.com>
Message-Id: <19890728011525.2.ALAN@PIGPEN.AI.MIT.EDU>
Date: Wed, 26 Jul 89 12:12:27 EDT
From: gls@Think.COM (Guy Steele)
...
So the main advantage of INF is that it signals an error telling me
that INF was the wrong thing, so that I can rewrite my code to use MIN
instead, right? :->
No, INF returns a result that causes an error to be signaled, so that you
can rewrite your code to avoid the overflow. You should still use INF so
that future bugs of a similar nature will be caught too!
But bucket 2148565200 *is* the last bucket. You have forgotten your
original premise:...
Quite right, I got my 10-digit numbers mixed up. I knew that the incorrect
bucket index had to be divisible by a moderate power of two (due to the
construction of the example) and then I momentarily forgot that Lisp
programmers no longer use octal all the time...
Date: Wed, 26 Jul 89 12:58:15 EDT
From: gls@Think.COM (Guy Steele)
(+ 1.0 1e20) ==> 1.0
Hm. My mom might complain about this one too. Maybe you meant
"1e-20"? Or else you got ripped off if you paid more than $2 for that
implementation.
*Cough* A typo. I hope everybody understood what I meant.
Suppose I was planning on feeding this result to MEMBER? or
ASSOC? -- isn't this just as bad as what MAX does?
No, it isn't, Alan, and here's why. Your example takes what we might
expect to be two things and makes them one....
OK, so it isn't -exactly- the same effect, but the parallel that I was
trying to draw is that you can write a piece of code that depends on the
ideal properties of the abstract function +, and you can write a program
that depends on the ideal properties of the abstract function MAX, and in
both cases you can be suprised.
I wonder, by the way, what those of you who insist that MAX must return
something EQV? to one of its arguments because "MAX computes -the- maximum
of a set of numbers", think should be the answer in the case of (MAX 1 1.0)?
Date: Wed, 26 Jul 89 13:05:35 EDT
From: gls@Think.COM (Guy Steele)
Actually, the remark that "inexact numbers just't don't behave like
numbers" prompts me to ask "are inexact numbers expected to behave like
objects"? Maybe inexact numbers should be totally excused from the
requirements of object identity. (They don't know just who they are,
so why should anyone else?) This also provides a loophole big enough
to drive a pdl-number through.
Indeed quite a large loophole. I want everyone to keep it clear that I am
-not- advocating anything like this. I am a believer in object identity
even for inexact numbers. Inexact numbers may not be "numbers" in some
sense of the word, but inexact numbers -are- objects. (They are objects
that -represent- numbers. Or perhaps more precisely, they are objects that
represent our knowledge of about certain numbers.) What we are arguing
about here is the contract of MIN and MAX, nothing more.
[ This paragraph is not addressed to Steele or any of the other current
participants in this discussion, but to casual readers of RRRS-Authors who
might read Steele's remarks here and jump to the conclusion that I am
advocating something radical that I am not. ]
Date: Wed, 26 Jul 89 14:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
... At least with floats the fact that games are being played is above
board, and you don't have to fail to conform in order to use standard
hardware.
... We have created a theory of numbers so strange that it's likely
that a noticeable fraction of would-be implementors will implement all
of the spec except for numbers.
I am not aware of any reasons why inexact numbers cannot be implemented
efficiently using standard floating point as the representation. The fact
that we have complicated arguments about the behavior of inexact numbers
does -not- imply that implementation of those behaviors needs to be
complicated.
Date: Thu, 27 Jul 89 10:33:25 EDT
From: gls@Think.COM (Guy Steele)
...
Incidentally, "The Brave Little Toaster" is pretty fair animation, great
storytelling for the age level it is nominally pitched at, good
characterization (given that the heroes are household appliances), and has
some fine parody sequences for us so-called grown-ups. (Maybe Alan will
have some differing opinion, and we can discuss *that* for a while. :-)
I'll agree with you on most of this. The animation did seem pretty
uninspired, but the producers clearly weren't aiming for great technical or
artistic achievement. I especially enjoyed the appliances-from-hell.
I'd give it a mild thumbs up.
∂28-Jul-89 1635 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #170
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Jul 89 16:35:08 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04585; Fri, 28 Jul 89 18:48:52 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28077;
28 Jul 89 17:49 EDT
Date: 28 JUL 89 17:21:59 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #170
To: Scheme@mc.lcs.mit.edu
Reply-To: Scheme@mc.lcs.mit.edu
Message-Id: <8907281749.aa28077@mintaka.lcs.mit.edu>
Scheme Digest #170 28 JUL 89 17:21:59 EDT
Today's Topics:
Scheme Release 7 Beta Test
Scheme Release 7 Beta Test
Elk (Extension Language Kit) submitted to comp.sources.unix
----------------------------------------------------------------------
Date: Thu, 27 Jul 89 00:52:27 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907270452.AA26278@zurich.ai.mit.edu>
Subject: Scheme Release 7 Beta Test
MIT Scheme release 7 is now available for beta test. This release
contains many notable changes:
* Liar, the native code compiler, is supported for 68020 and Vax
computers. Rough performance measurements indicate that it
produces code that is competitive with Orbit and Lucid Common Lisp
(although there's still some work left to beat them consistently).
High-quality debugging support is standard -- the debugger
provides nearly the same information for compiled and interpreted
code.
* Edwin, the Emacs-like text editor, is supported under curses and
X version 11. Unlike the stripped-down version supplied with TI
PC-Scheme, this is a fully-extensible editor with most of the GNU
Emacs features. Due to performance considerations it is likely to
be useful only on machines that have compiler support.
* A reference manual, written in Texinfo, is supplied. The manual
is still incomplete but even so documents a substantial part of
the system. Because it is written in Texinfo, it can be either
printed or browsed on-line with the Edwin (or GNU Emacs) info
subsystem.
* Two-dimensional line and point graphics support for X version 11
is standard. Color, border, size, and position controls are
provided.
Because this is a beta test, users should expect the installation to
be less than completely smooth. Although we have done extensive
debugging here at MIT, you should expect bugs as well. We solicit
your bug reports, criticisms, and any other comments about the
release.
A few important things are still missing, including: (1) detailed
documentation for using the compiler and editor, and (2) a
compatibility mode for S&ICP classes. We hope to remedy these, and
many other defects, by the end of August when the full release will
occur.
We've tested installation on the following machines, and would greatly
appreciate any efforts that you could make getting things running on
any other machines:
HP 9000 series 300 and 800 running HP-UX
Sun3 running SunOS
Vax running Ultrix
DS3100 running Ultrix
This release may be obtained by anonymous ftp to "zurich.ai.mit.edu"
(internet address 18.26.0.176), from the directory "pub/scheme-7.0/".
See the README file in that directory for further directions.
Because a number of people have had trouble using ftp to that machine,
we plan to distribute from a second host. When we have an alternate
host, it will be announced.
We will not be mailing tapes of this release until the beta test has
finished and the full release is out; however if you show up at MIT
with a 9-track magtape we'll be happy to put the software on it.
As usual, report bugs to
bug-cscheme@zurich.ai.mit.edu
If you receive this message from another source, and would like to be
included on the MIT Scheme mailing list, please send a request to
info-cscheme-request@zurich.ai.mit.edu
------------------------------
Date: Thu, 27 Jul 89 01:29:10 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907270529.AA26430@zurich.ai.mit.edu>
Subject: Scheme Release 7 Beta Test
The secondary host for distribution of Scheme Release 7 is the host
"prep.ai.mit.edu" (internet address 18.71.0.38). Use anonymous ftp
and look in the directory "pub/gnu/scheme-7.0/".
At present, due to space restrictions, this secondary site carries
only the minimum required installation files. None of the optional
files for source, documentation, etc. will fit there. If feasible, we
will make the rest of the distribution available there in the future.
------------------------------
Date: 26 Jul 89 13:19:26 GMT
From: Oliver Laumann <mcvax!unido!tub!net@uunet.uu.net>
Subject: Elk (Extension Language Kit) submitted to comp.sources.unix
Message-Id: <883@tub.UUCP>
I would like to announce the posting of Elk (the Extension Language
Kit) to comp.sources.unix. Elk is a Scheme interpreter intended to be
used as a general extension language interpreter. Interfaces to the
X11R3 Xlib and the Athena and HP widget sets are part of the distribution.
This might also be of interest to the readers of comp.soft-sys.andrew
because of the recent discussion about extension languages.
Attached to this article you will find a copy of the release notes.
Regards,
--
Oliver Laumann net@TUB.BITNET net@tub.UUCP
-----------------------------------------------------------------------
Elk Release Notes
-----------------
This is release 1.0 of Elk (The Extension Language Kit).
This is a production release.
Elk is a Scheme interpreter intended to be used as a general extension
language; it is also useful as a stand-alone implementation of Scheme.
One purpose of the Elk project is to end the recent proliferation of
mutually incompatible Lisp-like extension languages. Instead of
inventing and implementing yet another extension language, application
programmers can link the Scheme interpreter into their application
in order to make it extensible and highly customizable.
The Elk project was started in 1987 to support ISOTEXT, an ODA-based
document system (a WYSIWYG editor) that is being developed at the
Technical University of Berlin. Elk has been successfully demonstrated
as the extension language kernel of ISOTEXT, e.g. at the Hanover Fair 1989.
We feel that Scheme is better suited as a general extension language
than other Lisp dialects: it is sufficiently small to not dwarf the
application it serves and to be fully understood with acceptable
effort; it is orthogonal and well-defined. In addition, Scheme has
been recognized to be mature enough for national and international
standardization (IEEE P1178, ISO/IEC JTC1/SC22/WG16).
The Elk Scheme interpreter is R↑3RS compatible (with some minor exceptions
listed in a separate document); future releases will conform to the R↑4RS
and/or P1178 as soon as the respective standards become available.
Non-standard features of the Scheme implementation include:
o dynamic loading of object files
o creation of an executable image from the running
interpreter (``unexec'')
o a macro facility
o environments as first-class objects
o dynamic-wind, fluid-let
o autoloading, provide/require
The Scheme interpreter can easily be extended by application-specific
new types and primitive procedures. Such extensions are typically
written in C or C++ and dynamically loaded into the running interpreter.
The current release of Elk includes several such extensions, e.g.
interfaces to the X11 Xlib and to the application programmer interface
of the Xt intrinsics, and interfaces to the Athena widget set and the
HP widget set.
The software currently runs on Sun-3s with SunOS, ISI 680x0 with 4.2BSD
or 4.3BSD, Vax with 4.3BSD or Ultrix, and Intel 80386 with System V
Release 3. Porting instructions are included. Dynamic loading of
object modules is not supported under System V.
--
Oliver Laumann, Technical University of Berlin, Germany
Communications and Operating Systems Research Group
net@tub.BITNET Europe: unido!tub!net World: pyramid!tub!net
------------------------------
End of Scheme Digest
********************
∂28-Jul-89 1839 @mc.lcs.mit.edu,@life.ai.mit.edu:jar@sid.stanford.edu INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Jul 89 18:39:14 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA06202; Fri, 28 Jul 89 21:28:40 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01127;
28 Jul 89 21:06 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jul 89 19:20:27 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa23294;
28 Jul 89 11:15 EDT
Received: from zurich.ai.mit.edu ([18.26.0.176]) by life.ai.mit.edu (4.1/AI-4.10) id AA05753; Fri, 28 Jul 89 02:04:13 EDT
Received: from mojave.Stanford.EDU (mojave.stanford.edu) by zurich.ai.mit.edu; Fri, 28 Jul 89 01:59:21 edt
Received: from Edusa.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
id AA07578; Thu, 27 Jul 89 21:25:18 PDT
Message-Id: <8907280425.AA07578@mojave.Stanford.EDU>
Received: by sid; Thu, 27 Jul 89 21:27:48 pdt
Date: Thu, 27 Jul 89 21:27:48 pdt
To: Alan@reagan.ai.mit.edu
Cc: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Chris Hanson's message of Wed, 26 Jul 89 13:33:14 edt <8907261733.AA22254@zurich.ai.mit.edu>
Subject: INF/SUP/MIN/MAX
From: Jonathan Rees <jar%sid.stanford.edu@polya.stanford.edu>
Sender: jar@sid.stanford.edu
Date: Wed, 26 Jul 89 13:33:14 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Just for the record, so far I agree with you Alan. I've been
following the discussion but haven't said anything because I felt you
have been making arguments at least as good as any I could.
Ditto.
∂28-Jul-89 2243 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #171
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Jul 89 22:43:41 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA08719; Sat, 29 Jul 89 01:08:03 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03596;
29 Jul 89 0:40 EDT
Date: 29 JUL 89 00:06:57 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #171
To: Scheme@mc.lcs.mit.edu
Reply-To: Scheme@mc.lcs.mit.edu
Message-Id: <8907290040.aa03596@mintaka.lcs.mit.edu>
Scheme Digest #171 29 JUL 89 00:06:57 EDT
Today's Topics:
Equivalence predicates
Inquiry about functional command shells
----------------------------------------------------------------------
Date: Fri, 28 Jul 89 15:09:46 +0200
From: Oliver Laumann <unido!tub!net@uunet.uu.net>
Message-Id: <8907281309.AA26250@tub.UUCP>
Subject: Equivalence predicates
The Revised↑n Report on Scheme does not specify the result of
eq?, eqv?, and equal? applied to ports and end-of-file objects.
Is this intentional? E.g. what is the result of
(equal? (read) (read))
provided that both reads return an end-of-file object?
Regards,
--
Oliver Laumann net@TUB.BITNET net@tub.UUCP
------------------------------
Date: 28 Jul 89 18:15:47 GMT
From: John Lacey <lacey@tcgould.tn.cornell.edu>
Subject: Inquiry about functional command shells
Message-Id: <8512@batcomputer.tn.cornell.edu>
This coming fall I am going to embark on a programming project to build a
UNIX shell based on a functional programming paradigm. My initial
inclination is to build the shell from a Lisp interpreter/compiler---options
so far include MIT Scheme, Yale T, and perhaps XScheme or the recently
mentioned ELK embedded Scheme.
The main purpose is to combine the command and programming languages of the
environment into a single system. That is, the shell language would not
only be similar to the programming language, it would _be_ the programming
language.
So far, I have found several references to similar projects, and I would
like to find further references, as well as any comments about the project
or the language that anyone might have.
The most promising reference that I have is
_fsh - A Functional UNIX Command Interpreter_,
by Chris S. McDonald
Univ. of Western Australia
It appeared in Software: Practice and Experience, 17 (10) 685-700 (1987).
If anyone knows more about this project, or has used a similar shell, I
would greatly appreciate hearing from you.
Thanks,
--
John Lacey | cornell!batcomputer!lacey
lacey@tcgould.tn.cornell.edu | lacey@crnlthry.bitnet
------------------------------
End of Scheme Digest
********************
∂30-Jul-89 1023 @mc.lcs.mit.edu,@life.ai.mit.edu:jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk Re: INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Jul 89 10:23:25 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA18884; Sun, 30 Jul 89 13:09:48 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19972;
30 Jul 89 12:58 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Jul 89 12:53:23 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa19892;
30 Jul 89 12:48 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA18799; Sun, 30 Jul 89 12:48:52 EDT
Received: from NSFnet-Relay.AC.UK (nsfnet-relay.ac.uk) by zurich.ai.mit.edu; Sun, 30 Jul 89 12:44:57 edt
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa00343; 30 Jul 89 17:34 BST
Date: Sun, 30 Jul 89 17:36:25 BST
Message-Id: <11536.8907301636@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk>
Subject: Re: INF/SUP/MIN/MAX
To: Guy Steele <gls@think.com>, cph@zurich.ai.mit.edu
Cc: Alan@reagan.ai.mit.edu, KMP@stony-brook.scrc.symbolics.com,
RRRS-Authors@zurich.ai.mit.edu
From: Guy Steele <gls@think.com>
> Date: Wed, 26 Jul 89 15:49:33 edt
> From: cph@zurich.ai.mit.edu (Chris Hanson)
>
> [quotes Steele's arguments about Quux-head pennies, etc.]
> I don't buy these arguments: many of them have to do with side
> effects, and since when are there any side effects on numbers? So
> they don't apply.
>
> Granted. "Plus ca change, plus c'est la meme chose", as Sussman and I
> quoted in "The Art of the Interpreter". The more things change, the more
> they remain the same; that is, the notion of object identity may be linked
> to the notion of side effect. And yet, if numbers are not subject to
> side effects, in what sense can we say that 1 = 1, or that 1 /= 2 ?
I think this observation of numeric identity shows that identity can
be linked to side-effects, but also that identity doesn't require this
link. Indeed, I don't find the argument that there's some sort of
implicit potential side-effect involved in asking 1 = 1 very
convincing.
> I think that when we say 1 = 1, we are temporarily entertaining the
> possibility that the two instances of "1" represent *different* things,
> precisely so that we may then make the assertion that they are the same
> after all.
When I say "Nixon is the author of Six Crises", do this mean I'm
temporarily entertaining the possibliity that someone else wrote it?
Well, perhaps I'm at least entertaining the possibility that the
person I'm speaking to thinks so. But what if I say just "Nixon is
Nixon"? It may seem that I must have some possibility in mind that I
am trying to deny. But I don't think it's clear what this possibility
is unless I say something more. For example, I might say: "The person
you call 'Nixon' is the same person I know as 'Nixon', the author of
Six Crises, etc., and not two different people as we had once
supposed." But it's hard to see how there could be this kind of
confusion about "'1' as defined by Scheme". Indeed, it seems to me
that once we agree about what "Nixon" refers to, we can say "Nixon is
Nixon" without necessarily entertaining any possibility that Nixon
isn't Nixon.
So I don't think it's straightforward to conclude that when we
say 1 = 1, etc.
> If one of the 1's were not 1 after all, then things would be
> different, including the truth of the equality. This subjunctive
> hypothesis amounts to a side effect, for we are considering, hypothetically
> and however evanescently, a world altered from our own (whether by SETQ
> or by adding an entry to the head of an a-list).
But is every difference the result of a side-effect? Perhaps we're
just entertaining the possibility that "=" doesn't mean what we
thought it meant or that tokens like "1" refer to something different
each time.
So, I'm not sure we can take the side-effect reasoning this far.
But then I think it makes sense to talk of object identity even
when side effects are not involved, so I'm still inclined to
agree with Guy's earlier arguments.
Perhaps it would be better to use the more general notion of
"operational equivalence", though I don't know what the results
would be.
> Maybe the problem isn't the action of max or min, but eqv? If we
> considered equality as defined by = this question wouldn't come up.
> Maybe eqv? is making too fine a distinction.
>
> Indeed, and this is essentially the subject of the message I sent
> after this one (the one you replied to): maybe inexact numbers
> should not possess object identity. Please take this seriously.
> (Maybe it's the wrong idea, but it's not a frivolous idea, I think.)
I agree that we should take this suggestion seriously.
∂01-Aug-89 1716 @mc.lcs.mit.edu:hieb@iuvax.cs.indiana.edu revisiting lambda*
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Aug 89 17:16:40 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA16083; Tue, 1 Aug 89 20:07:48 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18025;
1 Aug 89 18:46 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Aug 89 17:38:27 EDT
Received: from IUVAX.CS.INDIANA.EDU by mintaka.lcs.mit.edu id aa14839;
1 Aug 89 14:46 EDT
Received: by iuvax.cs.indiana.edu
Date: Tue, 1 Aug 89 13:46:13 -0500
From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: revisiting lambda*
Message-Id: <8908011446.aa14839@mintaka.lcs.mit.edu>
I am of course pleased to see interest in lambda* among R*S readers. At this
point lambda* has yet to see enough use---"proof of principle"---to justify its
inclusion in an established language, which is what R* Scheme has become.
However, the concepts behind it have great potential and I would like to see
them more widely experimented with. At least part of it---the dispatch on
optional arguments---is already mature enough to warrant serious consideration
as a means for handling optional arguments in R* Scheme.
I think I should respond to the ongoing critique by Rozas to make sure
budding interest is not prematurely squashed! Some interesting language design
isues which have broad applications to ongoing R*S work arise.
A summary of the relevant notes:
-------------------------------------------------------------------------------
From: Guillermo J. Rozas <jinx@hpesogg.hp.com> Tue Jul 25 19:39:34 1989
Although I agree that there are interesting issues in lambda*, I think
that lambda* mixes up too many concepts and imposes implementation
restrictions that I'm not sure I like.
I envision something more primitive, and completely different. I
think that using lists, vectors, or special values to collect and pass
arbitrary numbers of arguments is spurious. Specific data structures
should be introduced by the user according to convenience or intent.
The arbitrary arity mechanism in the language should not be based on
arbitrary data aggragates at all, but on something more primitive, and
procedures (I think) are a good choice.
-------------------------------------------------------------------------------
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com> Fri Jul 28 13:44:50 1989
I also feel quite strongly that the following three issues are
separable. Lambda* jumbles them up, and that is my main problem with it:
1) Multiple values.
2) Dispatch on variable arity.
3) Acceptance of "unbounded" numbers of arguments.
I think many people agree that the current "dot notation" and apply
have some problems, but I don't think that replacing them with lambda*
solves them. The three issues above are (I think) independent, and
should be solved by independent mechanisms.
A second point is that I don't like special forms when procedures can
do the job, and all the three issues above can be solved as
efficiently by adding procedures as by adding special forms.
Special forms are syntactic cuteness that people who so desire can add
on top. Real men don't use macros :-)
--------------------------------------------------------------------------------
Clearly Rozas agrees with the primary premise of the lamda* paper, that "using
lists, vectors, or special values to collect and pass arbitrary numbers of
arguments is spurious. Specific data structures should be introduced by the
user according to convenience or intent." However, he seems to imply that
lambda* uses "special values" to pass arbitrary numbers of values. In fact,
lambda* uses special VARIABLES to pass arbitrary numbers of values---variables
which refer to multiple values. No new sort of data structure or value was
implied.
Of more general interest is Rozas' claim that lambda* "jumbles" independent
issues which would be better handled separately. I found it notable that his
alternative approach was based on Scheme procedures in all their glory, which
"jumble" many language features which could be treated separately. Consider
some of things achieved by procedures in Scheme:
* Passing parameters.
* Returning results.
* Binding and assignment of variables.
* Scoping of variables.
* Capture of free variables (lexical scoping and indefinite extent).
* Freezing of action (procedures are a form of "potential energy").
* Passing varying numbers of parameters.
* Access to primitive data structures (the magic of cons, car, etc).
* Access to continuations (call/cc).
* Converting lists to parameters (apply).
* Converting parameters to lists (dot interface).
Yet it is certainly this "lambda jumble" that makes Scheme what it is. I think
few Schemers would want to lose any of at least the first 6 of the above
properties of Scheme procedures. The others are more debatable, but are
certainly useful in practice.
Although lambda* adds to the jumble, I think it is the best means to date for
handling procedures which accept variable numbers of arguments. Perhaps
allowing procedures with variable numbers of arguments was our first mistake,
but we must make the best of it, which was the primary goal of lambda*. The
further issue of lambda* and multiple return values is orthogonal, but once
multiple return values are added to a language it becomes necessary to
integrate them smoothly with existing features. lambda* provides solid base
for adding multiple return values, but in no way depends upon their existence.
Finally, I think there is little justification for "proceduralizing"
everything. I for one am glad that I can write (if test then else) instead
of (ef test (lambda () then) (lambda () else)). Sometimes procedures are an
appropriate way to introduce language features. cons and call/c are examples
of such procedures. But not always. I like if and I don't think procedures
like SUPPLY-ARGUMENTS and MAKE-ARGUMENTS-COLLECTOR are an improvement to the
dot interface. (I realize Rozas was not submitting them for serious
consideration, but they are the only examples of what a "procedural" solution
might look like.)
Bob
∂01-Aug-89 1731 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #172
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Aug 89 17:30:50 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA16077; Tue, 1 Aug 89 20:04:28 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16823;
1 Aug 89 17:39 EDT
Date: 1 AUG 89 17:10:53 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #172
To: Scheme@mc.lcs.mit.edu
Reply-To: Scheme@mc.lcs.mit.edu
Message-Id: <8908011739.aa16823@mintaka.lcs.mit.edu>
Scheme Digest #172 1 AUG 89 17:10:53 EDT
Today's Topics:
Scheme Digest #171
----------------------------------------------------------------------
From: adams@daisy.cge.fr
Date: Mon, 31 Jul 89 09:39:42 +0200
Message-Id: <8907310739.AA06479@zephir.cge.fr>
Subject: Re: Scheme Digest #171
I would be quite interested in your project to write a shell etc. based
on a functional framework. I would also be interested in more info on
FSH (I remember reading the Software: Pract. & Exp. paper when it came
out). Would you please keep me posted.
Regards,
Drew ADAMS, Laboratoires de Marcoussis, Centre de Recherches de la Compagnie
Generale d'Electricite, Route de Nozay, 91460 MARCOUSSIS, FRANCE
Tel. +33 (1) 64.49.11.54, adams@crcge1.cge.fr ["one", not "ell"]
------------------------------
End of Scheme Digest
********************
∂01-Aug-89 1806 @mc.lcs.mit.edu,@life.ai.mit.edu:hal@zurich.ai.mit.edu Take Two
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Aug 89 18:06:10 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA16436; Tue, 1 Aug 89 20:57:07 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18965;
1 Aug 89 20:12 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Aug 89 19:49:40 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa15430;
1 Aug 89 15:44 EDT
Received: from zurich.ai.mit.edu ([18.43.0.179]) by life.ai.mit.edu (4.1/AI-4.10) id AA12829; Tue, 1 Aug 89 15:44:12 EDT
Received: from localhost by zurich.ai.mit.edu; Tue, 1 Aug 89 15:40:53 edt
Date: Tue, 1 Aug 89 15:40:53 edt
From: Hal Abelson <hal@zurich.ai.mit.edu>
Message-Id: <8908011940.AA10031@zurich.ai.mit.edu>
To: JMiller@crl.enet.dec.com
Cc: rrrs-authors@zurich.ai.mit.edu, Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: jmiller@crl.dec.com's message of Tue, 1 Aug 89 10:54:37 EDT <8908011454.AA01758@peanut.DEC.COM>
Subject: Take Two
Reply-To: hal@zurich.ai.mit.edu
I vote (c) -- selector semantics.
∂01-Aug-89 1810 @mc.lcs.mit.edu,@life.ai.mit.edu:jar@sid.stanford.edu Take Two
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Aug 89 18:09:53 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA16449; Tue, 1 Aug 89 20:58:42 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19094;
1 Aug 89 20:26 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Aug 89 19:53:42 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa18399;
1 Aug 89 19:30 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA15705; Tue, 1 Aug 89 19:30:44 EDT
Received: from mojave.Stanford.EDU (mojave.stanford.edu) by zurich.ai.mit.edu; Tue, 1 Aug 89 19:26:58 edt
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
id AA00928; Tue, 1 Aug 89 16:27:13 PDT
Message-Id: <8908012327.AA00928@mojave.Stanford.EDU>
Received: by sid; Tue, 1 Aug 89 15:56:37 pdt
Date: Tue, 1 Aug 89 15:56:37 pdt
From: Jonathan Rees <jar@sid.stanford.edu>
To: JMiller@crl.enet.dec.com
Cc: rrrs-authors@zurich.ai.mit.edu, Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: jmiller@crl.dec.com's message of Tue, 1 Aug 89 10:54:37 EDT <8908011454.AA01758@peanut.DEC.COM>
Subject: Take Two
Date: Tue, 1 Aug 89 10:54:37 EDT
From: jmiller@crl.dec.com
P.S. -- It's long past time that things got submitted to the librarian
(jar@zurich.ai.mit.edu?). I plan to kick the ball off shortly by
taking code from MIT Scheme that is portable and submitting that. Can
others do likewise?
I'd particularly like to see a fully portable string->number that
"blows up" only when it hits an implementation restriction -- i.e. one
that will reliably produce an exact integer 3 when given "#e6/2" even
in an implementation without ratnums.....I'm not even fully convinced
that this can be done correctly without assumptions about underlying
representations.
The librarian can be reached, as always, as
scheme-librarian@zurich.ai.mit.edu.
The librarian will not be active until some time after August 20. At
that time he intends to become more active, and it is hoped that the
library wil grow in size and popularity.
∂02-Aug-89 0359 ramsdell@linus.mitre.org Re: Take Two
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 2 Aug 89 03:59:29 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA20603; Wed, 2 Aug 89 06:46:57 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA08488; Wed, 2 Aug 89 06:42:19 EDT
Posted-Date: Wed, 02 Aug 89 06:42:16 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA07091; Wed, 2 Aug 89 06:42:17 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908021042.AA07091@huxley.mitre.org>
To: JMiller@crl.enet.dec.com
Cc: rrrs-authors@life.ai.mit.edu
Subject: Re: Take Two
In-Reply-To: Your message of Tue, 01 Aug 89 10:54:37 -0400.
<8908011454.AA01758@peanut.DEC.COM>
Date: Wed, 02 Aug 89 06:42:16 EDT
I vote (a) -- Status quo.
∂02-Aug-89 1357 @mc.lcs.mit.edu:dyb@iuvax.cs.indiana.edu Re: Take Two
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 2 Aug 89 13:56:54 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA27429; Wed, 2 Aug 89 16:41:55 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01969;
2 Aug 89 15:56 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 2 Aug 89 15:25:55 EDT
Received: from IUVAX.CS.INDIANA.EDU by mintaka.lcs.mit.edu id aa20924;
1 Aug 89 23:30 EDT
Received: by iuvax.cs.indiana.edu
Date: Tue, 1 Aug 89 22:30:19 -0500
From: "R. Kent Dybvig" <dyb@iuvax.cs.indiana.edu>
To: JMiller@crl.enet.dec.com
Subject: Re: Take Two
Cc: rrrs-authors@mc.lcs.mit.edu
Message-Id: <8908012330.aa20924@mintaka.lcs.mit.edu>
I vote for option (c), selector semantics. I think of min and max as
conditional expressions, which I guess makes me a C weenie.
∂06-Aug-89 1352 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com revisiting lambda*
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Aug 89 13:50:40 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA14805; Sun, 6 Aug 89 16:30:20 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07367;
6 Aug 89 16:27 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Aug 89 16:27:59 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07354;
6 Aug 89 16:25 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA14710; Sun, 6 Aug 89 16:08:12 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Sun, 6 Aug 89 16:04:01 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA21463; Sun, 6 Aug 89 13:07:05 pdt
Message-Id: <8908062007.AA21463@sde.hp.com>
Received: by hpesogg; Sun, 6 Aug 89 13:06:26 pdt
Date: Sun, 6 Aug 89 13:06:26 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: hieb@iuvax.cs.indiana.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Robert Hieb's message of Tue, 1 Aug 89 13:46:13 -0500 <8908011446.aa14839@mintaka.lcs.mit.edu>
Subject: revisiting lambda*
Reply-To: jinx%hpesogg@sde.hp.com
[
Sorry if you receive multiple copies, but I've had some problems
mailing stuff to rrrs-authors recently.
]
However, he seems to imply that
lambda* uses "special values" to pass arbitrary numbers of values. In fact,
lambda* uses special VARIABLES to pass arbitrary numbers of values---variables
which refer to multiple values. No new sort of data structure or value was
implied.
There are two different ways to look at it. You are "blaming" the
variables, rather than the values that they hold. Ultimately you are
adding a new kind of object, or a new kind of variable, that I (and
many other people) consider unnecessary and distasteful. I also
suspect that if you try to write the semantics for it, you will find
that it is easier to think about the value being "funny", rather than
the variable.
Of more general interest is Rozas' claim that lambda* "jumbles" independent
issues which would be better handled separately. I found it notable that his
alternative approach was based on Scheme procedures in all their glory, which
"jumble" many language features which could be treated separately. Consider
some of things achieved by procedures in Scheme:
This argument is very strange. You are not trying to defend lambda*,
you are instead saying something like
"Since there is already something broken in the language, it is not
surprising that we want something even more broken, and furthermore,
how come you don't argue about the broken things already there?".
Perhaps you are trying to discredit me, rather than my argument? I
hope not.
I agree that lambda mixes up certain concepts. Both lambda* and what
I hope to see fix some of these problems. You are assuming that I'm
just being facetious by arguing against lambda* while you don't hear
me arguing against lambda. The reason I argue against lambda* is
because it is not yet in the language. Perhaps if lambda were being
considered for addition, I would be arguing against it too. That has
not been feasible since 1975. Another reason why I (and others)
haven't tried to replace lambda is that we don't have anything better,
although perhaps John Lamping's thesis points in the right direction.
After examining your list of capabilities for lambda/procedures, I
detect a basic confusion in your argument (or your interpretation of
my argument):
You must distinguish between the capabilities of procedures, and the
capabilities of the primitive forms (and procedures) that create
procedures. You don't do that.
I don't object to procedures being able to do everything. Scheme is
an applicative language, and I don't want to change that. I do object
to making each individual primitive form that creates procedures be
able to do everything. I don't want LAMBDA to become Scheme's kitchen
sink in the same way that LOOP is CommonLisp's kitchen sink (or one of
its many kitchen sinks).
Let's examine your list element by element and see whether your
objections are objections against lambda or against procedures in
general. Again, I have no objections to procedures being able to do
everything. I have objections against individual special forms (be it
lambda or lambda*) being able to do everything.
* Passing parameters.
This has nothing to do with lambda, or ultimately even with
procedures. Procedure applications (ie. combinations) pass parameters.
Procedures RECEIVE parameters. More on this below.
* Returning results.
This has nothing to do with either lambda or procedures. Expressions
"return" (or have) values. Therefore lambda expressions have values,
combinations have values, and procedure bodies have values.
Perhaps you are confusing the concept of procedures or lambda versus
their implementation with standard (procedure based) compiler technology.
* Binding and assignment of variables.
Lambda definitely binds variables, but I hardly see how it assigns
variables. Assignment is handled by set! Procedures don't bind
anything. They allocate storage for variables, and potentially mutate
the storage of preallocated variables.
* Scoping of variables.
Definitely, but this is really the same as the point about binding,
since when you have the ability to bind, you must specify how
conflicts are resolved. You are not saying anything new.
* Capture of free variables (lexical scoping and indefinite extent).
Again, this is the same point.
* Freezing of action (procedures are a form of "potential energy").
Yes. But this is a property of procedures, not (inherently) of lambda.
* Passing varying numbers of parameters.
I hope you mean receiving. Otherwise you are talking about
combinations or APPLY. If you are talking about receiving, your point
is ambiguous:
- Do you mean that procedures can accept more than one argument, ie. are
you talking about currying?
I certainly don't advocate for a curried language. I don't see any
advantage (pragmatic or aesthetic) to that.
- Do you mean that a given procedure created by lambda can accept an
unbounded number of arguments, ie. dotted parameter lists?
This point is mentioned below. At any rate, individual procedures
should certainly be able to receive any number of arguments, but it
doesn't follow that the same primitive must be used to construct all
of these procedures.
* Access to primitive data structures (the magic of cons, car, etc).
This has nothing to do with lambda.
* Access to continuations (call/cc).
Again, this has nothing to do with lambda. As an aside, I think that
the fact that "primitive" continuations are invokable is a mistake,
but it is to late to fight this battle.
* Converting lists to parameters (apply).
This has nothing to do with lambda. I still think that it is funny,
and that is what prompted my messages. Perhaps you've forgotten that.
* Converting parameters to lists (dot interface).
Both you and I are trying to fix this. Don't accuse me of defending
it.
Yet it is certainly this "lambda jumble" that makes Scheme what it is. I think
few Schemers would want to lose any of at least the first 6 of the above
properties of Scheme procedures. The others are more debatable, but are
certainly useful in practice.
As I stated before, you are confusing the power of procedures with the
capabilities of lambda. The power of procedures is what makes Scheme
what it is, not lambda per se!
Although lambda* adds to the jumble, I think it is the best means to date for
handling procedures which accept variable numbers of arguments. Perhaps
allowing procedures with variable numbers of arguments was our first mistake,
but we must make the best of it, which was the primary goal of lambda*. The
further issue of lambda* and multiple return values is orthogonal, but once
multiple return values are added to a language it becomes necessary to
integrate them smoothly with existing features. lambda* provides solid base
for adding multiple return values, but in no way depends upon their existence.
I think that lambda* was valuable in pointing out a different way of
handling dispatch on number of arguments received. There are problems
with the lambda* model, just as there are problems with the #!optional
(or &optional) model. I think that the rest argument feature is much
more questionable (and most people agreed at Snowbird), and
furthermore, I believe strongly that multiple values should be handled
by an independent mechanism. I'm not saying that lambda* is a
"waste". I'm just saying that it is no panacea, and I would like to
isolate what I consider to be its good features from what I consider
to be its bad features.
Finally, I think there is little justification for "proceduralizing"
everything. I for one am glad that I can write (if test then else) instead
of (ef test (lambda () then) (lambda () else)). Sometimes procedures are an
appropriate way to introduce language features. cons and call/c are examples
of such procedures. But not always. I like if and I don't think procedures
like SUPPLY-ARGUMENTS and MAKE-ARGUMENTS-COLLECTOR are an improvement to the
dot interface. (I realize Rozas was not submitting them for serious
consideration, but they are the only examples of what a "procedural" solution
might look like.)
I hope you mean (test (lambda () then) (lambda () else)). Besides
isn't this what IF is ultimately? :-)
This is clearly a matter of aesthetics, and yours and mine differ (not
surprising given our different backgrounds). My PERSONAL preference
is for new capabilities to be added in the form of procedures, not in
the form of special forms. Assuming that we ultimately agree on
macros (as impossible as that may seem right now), everyone can build
their own cutsey syntax on top of the "raw capability". I don't
advocate for anyone to necessarily use the primitive capabilities
directly, but I would like them to capture the essence of the concept,
and then people can abstract them away in any way they want.
The reason why I believe that capabilities should be added as
procedures, rather than syntax, is that I view syntax as a shorthand,
whose only purpose is legibility within context of the individual
program I am dealing with. Since the legibility needs of individual
programs and programmers vary, I don't like to impose any particular
shorthand or syntactic model on anyone. I believe that the
capabilities should be available by other means, and individual
programmers should map into them in whichever way they find
convenient at any point in time.
∂07-Aug-89 1734 @mc.lcs.mit.edu,@LIFE.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu LIST?
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Aug 89 17:33:44 PDT
Received: from MINTAKA.LCS.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB00489; Mon, 7 Aug 89 20:22:53 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21088;
7 Aug 89 20:03 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 7 Aug 89 20:03:25 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21063;
7 Aug 89 20:01 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00247; Mon, 7 Aug 89 20:01:19 EDT
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Mon, 7 Aug 89 19:57:57 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA04273; Mon, 7 Aug 89 17:01:01 PDT
Received: by spencer.cs.uoregon.edu; Mon, 7 Aug 89 17:01:02 PDT
Date: Mon, 7 Aug 89 17:01:02 PDT
From: will@cs.uoregon.edu
Message-Id: <8908080001.AA04985@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: LIST?
Add LIST?.
Jim Miller:
For virtually every data type mentioned in a procedure header line in
R4RS there is either an existing predicate in the language (string?
for string, vector? for vector, rational? for q_{n}, etc.) or a
trivial piece of code (like (lambda (k) (and (integer? k) (exact? k)
(positive? k))) for k_{n}). Not so for (proper) lists referred to as
"list" in the header line. It was our intention to have P1178 make
this connection explicit, whether or not R4RS chooses to do so, and
the missing predicate for proper lists causes a problem.
We had not planned to ask RNRS to change to add such a test. But
someone else has, so I'd like to support the addition of the predicate
LIST? that tests for proper lists. I don't mind if you call it
PROPER-LIST?, but I prefer the other name, especially since the
language of the report is very clear about the definition of a list,
and it excludes both cdr-circularity and dotted tails. Another
predicate might be of interest to RnRS (NOT-TAIL-CIRCULAR? or some
such) but you won't hear me agitating to have that added to the IEEE
proposal.
Several have spoken in favor of this procedure, and none have opposed it.
There has been some debate about the name; a minority prefers PROPER-LIST?
to LIST?. The minority consists of two people, since I have changed my
mind and now prefer LIST?. To summarize that debate, LIST? is more
consistent with the terminology used in Scheme but PROPER-LIST? is more
consistent with the terminology used in Common Lisp.
I will add LIST? to the R3.99RS and R4RS as an essential procedure provided
the authors will join me in a rousing chorus of "YES, YES!". Proposed
wording:
(LIST? obj) essential procedure
List? returns #t if obj is a list of finite length, and otherwise
returns #f.
(list '(a b c)) ==> #t
(list '()) ==> #t
(list '(a . b)) ==> #f
(let ((x (list 'a)))
(set-cdr! x x)
(list? x)) ==> #f
Peace, Will
∂07-Aug-89 1756 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu sequential order of evaluation
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Aug 89 17:56:20 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00704; Mon, 7 Aug 89 20:41:51 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21145;
7 Aug 89 20:09 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 7 Aug 89 20:09:34 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21067;
7 Aug 89 20:01 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00255; Mon, 7 Aug 89 20:01:49 EDT
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Mon, 7 Aug 89 19:58:28 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA04280; Mon, 7 Aug 89 17:01:42 PDT
Received: by spencer.cs.uoregon.edu; Mon, 7 Aug 89 17:01:45 PDT
Date: Mon, 7 Aug 89 17:01:45 PDT
From: will@cs.uoregon.edu
Message-Id: <8908080001.AA04992@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: sequential order of evaluation
Indeterminate order of evaluation of expressions in a procedure call.
Bill Rozas:
Any sequential order is the intention. Interleaving should not be
allowed because there are no locking primitives to serialize side
effects.
Chris Hanson:
Certainly the implementation is free to use any SEQUENTIAL order.
It has never been clear to me whether the specification permits
simultaneous evaluation of two different arguments.
Mike Shaff:
This being the case (and presuming this is the generally agreed thinking)
shouldn't this choice be made more explicit. I think the absence of said
locking primitives (at the current time) is an issue whose ramifications
should be noted.
The choice is explicit in the rather informal formal semantics, which says
the expressions must be evaluated sequentially in some permuted order.
Thus it is ok to evaluate
((f (car x)) (g (car x)))
as though it were
(let* ((t1 (f (car x)))
(t2 (g (car x))))
(t1 t2))
or
(let* ((t2 (g (car x)))
(t1 (f (car x))))
(t1 t2))
but it is not ok to evaluate it as though it were
(let* ((t0 (car x))
(t1 (f t0))
(t2 (g t0)))
(t1 t2))
or
(let* ((t0 (car x))
(t2 (g t0))
(t1 (f t0)))
(t1 t2)).
The problem with saying that the evaluation must be sequential is that the
word "sequential" isn't very well-defined. Some people think only the first
of the four is sequential, and some think all four are sequential.
How do the authors feel about adding the following note to section 4.1.3?
Note: Although the precise order of evaluation is unspecified, the
expressions must be evaluated without interleaving. Interleaving is
not allowed because Scheme provides no facilities for serializing
concurrent side effects.
∂07-Aug-89 1949 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu R3.99RS issues (long message)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Aug 89 19:49:14 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01437; Mon, 7 Aug 89 22:30:28 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21149;
7 Aug 89 20:09 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 7 Aug 89 20:09:53 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21076;
7 Aug 89 20:03 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00266; Mon, 7 Aug 89 20:03:03 EDT
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Mon, 7 Aug 89 19:59:41 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA04281; Mon, 7 Aug 89 17:02:51 PDT
Received: by spencer.cs.uoregon.edu; Mon, 7 Aug 89 17:02:53 PDT
Date: Mon, 7 Aug 89 17:02:53 PDT
From: will@cs.uoregon.edu
Message-Id: <8908080002.AA05003@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: R3.99RS issues (long message)
No less than 12 issues, by my count, have been debated here since I lost
contact with the net. I'll be responding to some of them separately. For
the others, this message summarizes my perception of the consensus or lack
thereof for purposes of the R4RS.
William Clinger
--------------------------------------------------------------------------------
Timing of the R3.99RS, R4RS.
Mike Shaff:
I am definitely in favor of moving forward on issues and getting the
report out to the public, however the latest version of the report that
I have (via zurich) still seems to have some areas that I thought were to
be part of the document (per L&FP such things as macros, name
regularization, etc were to be 'rubber stamped' by the group). Is there
to be another beta release *before* the submission to P1178? If not, what
happened to those and other favorites?
There will not be a beta release before submitting R3.99RS to P1178 because
there isn't time if P1178 is to circulate a draft IEEE standard before its
next meeting. Matters for which we have not reached consensus will have
to wait for the R5RS. There were only two things that the Snowbird meeting
"rubber stamped" in advance: clarification of the numeric procedures, and
macros. On the matter of regularization, it was agreed that Morry Katz would
develop a proposal for consideration over the net, but the Snowbird meeting
did not commit itself to accepting such a proposal.
With regard to the numeric procedures, we appear to have reached consensus
on everything except MIN and MAX; at worst I can leave MIN and MAX out of
the R4RS, but I expect we will do better than that. The macro committee
has thus far failed to agree on a proposal. The plan is for the R4RS (but
not the R3.99RS) will have an appendix that describes (at least) two
incompatible macro proposals and the issues that have prevented them from
being resolved; this should be the only substantial difference between the
R3.99RS and the R4RS. We do not have consensus on wholesale regularization,
but some regularization is occurring anyway (see below).
Pavel Curtis:
I'd rather that we did not cut off debate on R4RS at the end of this
month. It seems to me that there are several reasonably important
issues currently on the table that could make it into R4RS in the very
near future (e.g., uniform definition semantics, fluid binding, and
regularization of procedures). I would hate to see R4RS come out so
little changed from the previous report; in a sense, what's the point?
The point is that there should be a version of the RnRS that corresponds to
the P1178 draft. The P1178 committee has committed itself to follow the RnRS,
not to lead it. The changes that Pavel mentions are upwardly compatible with
what will be in the R4RS, so there's no reason to delay the R4RS on their
account.
--------------------------------------------------------------------------------
Flushing ELSE.
Morry Katz:
....I therefore advocate that we remove ELSE from the list of syntactic
keywords and replace ELSE by #T in the COND examples in RNRS....
This proposal has not attracted support, and is about to die for lack of a
second.
--------------------------------------------------------------------------------
Fluid variables or cells.
There seems to be agreement in principle but little consensus on details.
I think this is a good topic for R5RS but not for R4RS.
--------------------------------------------------------------------------------
FORCE and DELAY.
Mike Shaff:
Force and delay are currently in totally separate sections of R3.95RS
which can lead readers to hours of fun and enjoyment. Perhaps the
Delayed Evaluation section (4.2.5) can be made a subsection of Control
Features (6.9) and expanded to include force.
Sections 4.2.5 and 6.9 refer to each other explicitly. I can see how this
might cause a minute or two of page-flipping, but I think only a very
creative reader could derive hours of fun and enjoyment from it.
--------------------------------------------------------------------------------
Add CONTINUATION?
This issue has been withdrawn. In the message withdrawing this issue, Morry
Katz said:
I believe that PROCEDURE? is a serious misnomer. The function should
really be called APPLICABLE?.
All applicable objects described in R4RS are procedures, and vice versa, so
PROCEDURE? is no more a misnomer than APPLICABLE?. The name has been
debated twice in the last five years, and PROCEDURE? has won out both times.
--------------------------------------------------------------------------------
EQV? on numbers.
Jim Miller:
I thought that
(and (number? x) (number? y) (= x y)) implied
(eqv? x y).
By my reading of R3.95RS this isn't true (consider x=3 and y=3.0),
although I believe
(and (number? x) (number? y) (eqv? x y)) implies
(= x y)
Have I got this right?
Yes. In fact, my reading is that
(and (number? x) (number? y) (eqv? x y))
is equivalent to
(and (number? x) (number? y) (eqv? (exact? x) (exact? y)) (= x y)).
Pavel Curtis:
I would be unhappy with any statement that distinguished between the
behavior of, for example, the car cell of a pair and the contents of a
lexical variable...
The discussion at the recent P1178 meeting addressed both, though this
may not have been reflected by the minutes.
In my separate message on MAX and MIN, I argue that the requirement that
EQV?-ness be preserved should not be strengthened to a requirement that
EQ?-ness be preserved. I will expand that argument if people want me to.
--------------------------------------------------------------------------------
Add bitwise logical operation on exact integers (bitvectors, whatever).
This sounds like an excellent proposal for the yellow pages, and later for
inclusion in R5RS.
--------------------------------------------------------------------------------
Require left-to-right evaluation of internal definitions.
Pavel Curtis:
Given your retraction of this objection and John's and my unanswered
refutations of your first one, may we assume that you now support the
proposal to unify definition semantics? If not, could you say more?
I remember that you sent some messages denying my first objection, but I
don't recall any refutations of it.
I still prefer that the order of evaluation of internal definitions be left
unspecified, for the same reason that the order of evaluation of arguments
in a procedure call is unspecified. In both cases the context is such that
the order of evaluation ordinarily would not matter even if it were
specified. By leaving the order of evaluation unspecified, we save the
reader of a correct program from having always to consider the remote
possibility that the order is significant.
The obvious "disadvantage" of leaving the order unspecified is that people
who want to use side effects cannot use a tacit sequencing implicit to the
internal definitions or arguments, but must use an explicit BEGIN instead.
I maintain that this is actually the great advantage of leaving the order
unspecified.
The real disadvantage of leaving the order of evaluation unspecified is that
it becomes easier to write incorrect code. In my opinion this has not been
an important problem.
An aesthetic disadvantage in the case of internal definitions is that the
order of evaluation *is* specified for top-level definitions. I maintain
that this inconsistency results from our current compromise with file-based
program structures and separate compilation---matters that aren't even
mentioned in the Report, but influence it regardless. I too would like to
remove this inconsistency, but would prefer to fix it by removing the
implicit sequencing of top-level definitions. I hope this will be possible
in a future module facility or other extension for programming-in-the-large.
For all that, I repeat my earlier statement that I am not strongly opposed
to requiring that internal definitions be evaluated from left to right.
I am merely opposed. I will certainly implement this change if the authors
want me to.
--------------------------------------------------------------------------------
Why aren't more procedures required to return exact integers more often?
Alan Bawden:
Actually, I'd be more interested to know what -isn't- on the list. I'll
bet SQRT isn't there because people think that SQRT of an exact 4 should be
allowed to return something inexact rather than an exact 2. Am I right?
I suspect that if I understood more about this "list" I would argue that
-all- numeric functions belonged on it (including SQRT).
Bill Rozas:
Correct. I suppose it's a matter of practicality -- nobody wanted to
commit to implement `sqrt' to handle this case specially, presumably
because such behavior isn't too interesting. To take it further, I
suppose it wouldn't hurt to add the transcendental functions to the
list....The only good reason why `/' and `sqrt' should not be in the
list is efficiency and implementation complexity. Maybe that's not
good enough....
I suspect that there's no argument for keeping the transcendental
functions out of the list since my intuition tells me that there is no
case where integer arguments provide an integer result; if there is
such a case, it's probably pretty obscure...A similar argument holds
for `make-polar' and `angle'....
Here's the cases I could think of that would require special treatment:
(exp 0), (log 1), (sin 0), (cos 0), (tan 0), (asin 0), (acos 1), (atan 0),
(atan 0 n), (make-rectangular n 0), (make-polar n 0), (angle n),
(magnitude n); where n is an exact but not necessarily non-negative
integer.
Summary: the only procedures that seem to matter are `/' and `sqrt',
and the argument in favor of excluding them is pragmatic.
Scheme would be simpler if we could just say that with the exception
of EXACT->INEXACT, all procedures in section 6.5 that return a numeric
result will return an exact integer result provided all their arguments
are exact integers and the mathematically expected result is representable
as an exact integer within the implementation.
I think the argument in favor of simplicity outweighs the pragmatic
argument, partly because the pragmatic argument is weak. It isn't very
hard to handle the special cases, and it's unlikely that SQRT needs to be
particularly fast on exact integers. I propose that we make this change
in R5RS.
Peace, Will
∂07-Aug-89 2002 @mc.lcs.mit.edu,@LIFE.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu MIN and MAX (long message)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Aug 89 20:02:10 PDT
Received: from MINTAKA.LCS.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB01536; Mon, 7 Aug 89 22:47:57 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21252;
7 Aug 89 20:16 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 7 Aug 89 20:16:23 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21158;
7 Aug 89 20:09 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00343; Mon, 7 Aug 89 20:09:54 EDT
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Mon, 7 Aug 89 20:06:31 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA26857; Mon, 7 Aug 89 16:02:43 PDT
Received: by spencer.cs.uoregon.edu; Mon, 7 Aug 89 16:02:42 PDT
Date: Mon, 7 Aug 89 16:02:42 PDT
From: will@cs.uoregon.edu
Message-Id: <8908072302.AA04327@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: MIN and MAX (long message)
I agree with almost everything Alan Bawden and Mitch Wand have said
concerning MIN and MAX, so I will try to avoid repeating their
arguments in this note. The purpose of this note is to argue:
* Although the concept of exactness is a new and useful idea, it
is not a radical new idea. Programmers who naively assume that
inexact numbers are just another name for floating point numbers
are unlikely to get into any trouble they wouldn't already be in
with floating point. Furthermore the concept of exactness does
not entail any loss of efficiency.
* The controversy concerning the semantics of MIN and MAX has nothing
to do with the fact that Scheme does not require inexact numbers to
be represented in floating point format. It has to do with the
relationship between exact and inexact numbers (by whatever names
you want to call them) in a generic arithmetic system.
* No major programming language adopts either semantics that we are
considering for MIN and MAX. In particular, I think Guy was pulling
our collective leg when he claimed that MIN and MAX act as
conditionals in C.
* Certain statements that have been made in this discussion deserve
correction, qualification, or elaboration.
--------------------------------------------------------------------------------
Alan Bawden:
I've never heard users asking for the notion of exactness/inexactness at
all. Ask them what they want, and they will probably tell you that they
want IEEE floating point. As I have said before, I think it would be 100%
reasonable for Scheme to do what every other language does, and adopt some
reasonable set of rules for the behavior of floating point. Unfortunately,
Scheme decided to go in a different direction....
You might be shocked by how little "every other language" has to say about
what floating point is and how it behaves. A lot of machines don't support
IEEE floating point very well, so language designers have to be pretty vague
about floating point if they want their language to run well on popular
hardware.
At Brandeis we asked ourselves what was distinctive about floating point,
and why we needed it. The answer was that floating point was inexact, and
we needed it for efficient (though approximate) calculations with real
numbers. Instead of writing a vague description of how floating point
arithmetic behaves in Scheme, we wrote a vague description of how
inexact arithmetic behaves.
Although the Scheme report explicitly recognizes that non-floating-point
implementations of inexact arithmetic are possible, I suspect that most
language standards are vague enough that non-floating-point implementations
of their "real" or "float" types would be just as legal as in Scheme. So
I don't think we've done anything radical by allowing non-floating-point
implementations of inexact arithmetic.
Furthermore I don't think many programmers would notice the difference if
a good non-floating-point implementation of inexact numbers were used.
People doing serious calculations would notice and gripe, but they might
gripe about IEEE arithmetic as well (because, for example, its roundoff
characteristics are different from those of the Cray their programs have
been written for). If people doing serious calculations have technical
complaints about the non-floating-point implementation, well, maybe the
implementors should listen to them. (Now that would be radical!)
Kent Pitman:
....If Scheme numbers are to persist
in their current form, I would like to be able to speak as confidently
about their demonstrated usefulness, and I don't now feel that I have
the ammunition to do so.
Here are four benefits, arranged in decreasing order of importance by
my estimate. The basic argument in favor of the R3.95RS semantics for
MIN and MAX is that any other semantics would weaken the most important
benefit by adding yet another hypothesis.
* If a calculation yields an exact result, and the calculation did
not involve any predicates on inexact numbers, and did not call
INEXACT->EXACT, then the result is correct.
* The rules for calculating with exact numbers are such that the
extra hypotheses in the sentence above can often be checked
statically.
* The integers are a subset of the rationals, which are a subset of
the reals, which are a subset of the complex numbers.
* The ODD?, EVEN?, QUOTIENT, REMAINDER, MODULO, GCD, LCM, NUMERATOR,
and DENOMINATOR procedures accept inexact as well as exact
arguments.
Kent Pitman:
....It would be one thing if it -also-
provided floats, so that people could get real work done while they
waited for the other stuff to get field tested, but my own cynical
viewpoint is that--for quite a while yet, anyway-- implementations are
likely to be either correct or efficient, but not both. At least with
floats the fact that games are being played is above board, and you
don't have to fail to conform in order to use standard hardware.
Since floating point is not only a permitted representation for inexact
numbers but is in fact the typical representation, I don't understand
this argument at all. Arithmetic in Scheme is as efficient as generic
arithmetic in, say, Common Lisp.
I agree that it will take a year or two for people to get the bugs out
of their systems. In MacScheme 2.02, for example, the comparison
operators aren't transitive yet, the NUMBER->STRING, STRING->NUMBER, and
EXACT->INEXACT procedures aren't always good to the last bit, and the
MIN and MAX procedures still act as selectors. These are the only
arithmetic bugs I know of, six months after product release. None have
to do with exactness or inexactness, since they would remain bugs even
if Scheme were to require floats instead of inexact numbers.
Guy Steele Jr:
...every C weenie has the formula
#define max(x,y) ((x) > (y)) ? (x) : (y)
engraved in his little weenie brain. See? MAX really is a conditional.
I'm not much of a C weenie, and I don't have a description of the
proposed (or actual?) ANSI standard, but I think I know enough C to
suspect that Guy didn't mean for us Scheme weenies to take this seriously.
When examined more closely, Guy's example shows that C weenies think more
like me than like Guy. (This doesn't surprise me, unfortunately.)
C is a statically typed language, with very little polymorphism, that
regards ints and floats as different types. (I'm going to speak as
though all the different integer types were collapsed into one type, and
all the different float types into one type.) The two alternatives of
a conditional expression must have the same type, or else be convertible
to the same type using C's conversion rules. If you define max as Guy
suggested and then write max(2.5, 1000) as an expression, then the result
of that expression will be a float (1000.0), not an int.
If you write max(2.5, 1000) in a context that expects an int, then the
floating point 1000.0 will be converted back into an int (1000). (It
isn't wise to regard that conversion as part of the expression's
semantics, because you would then have to believe that max(2, 1000.5)
also evaluates to an int.) Hence max(2.5, 1000) in an int context is
really the equivalent of (INEXACT->EXACT (TRUNCATE (MAX 2.5 1000))) in
Scheme.
So if MAX really is a conditional in C, then (MAX 2.5 1000) ==> 1000.0
is consistent with MAX being a conditional. It seems that Guy's example
actually supports the R3.95RS semantics he was arguing against.
To my knowledge, no major programming language defines MAX so that
MAX of a floating point 2.5 and an exact integer 1000 is guaranteed
to be an (exact) integer. Common Lisp, which explicitly leaves it up
to the implementation, comes the closest. [My original posting to the
effect that Common Lisp requires (MAX 2.5 1000) to be 1000.0 was
incorrect, as Guy pointed out.]
With most C compilers, it is true that the result of max(x, y) will
always be equal to one of the arguments. This essentially results
from the poverty of C's representations. The R3.95RS semantics of
MAX allows this property to be achieved in Scheme the same way it
is achieved by C:
* Don't implement exact arithmetic for any types except integers.
* Limit the range of exact integers to +-9007199254740992.
(Any smaller range will work too.)
* Represent inexact reals as IEEE 64-bit floats.
Hence one could say that the R3.95RS semantics, like Common Lisp, allows
(but does not require) MAX to return a result that is not equal to any
of its arguments---but it would be misleading. [Apologies to RMN.]
Guy Steele Jr:
(1) I see no reason why the rules of inexact contagion should
apply to MAX. As Pavel has observed, >= does not return an
inexact boolean. (If >= were to be three-valued (yes/no/maybe)
then it would be more consistent.)
MIN and MAX don't return booleans. With the R3.95RS semantics, my
faith in an exact result is threatened only by predicates and by
INEXACT->EXACT. I'm not happy about having to remember those
exceptions, but I'd be even less happy if I had to remember them as
"predicates, INEXACT->EXACT, MIN, and MAX". The predicates and
INEXACT->EXACT are pretty easy to remember because they seem so
inevitable, but MIN and MAX would look like they made the list
because someone hadn't been thinking very clearly.
I'm not convinced by the argument that MIN and MAX are mere comparisons,
not computations, possibly because I know how much computation a mere
comparison is likely to take in Scheme when one argument is exact and
another inexact.
Alan Bawden:
....If the multiplication overflows the range of exact integers in
some implementation and returns an inexact, then the division will
return an inexact as well, and then VECTOR-REF will signal an error....
Guy Steele Jr:
Depends on why I put the MIN in there. If I put it in precisely to
guard against indexing off the end of the vector when running in
broken implementations that think 32 bits is enough to count anything
interesting at all, then the program is doing its job, and MIN is
exactly what I wanted.
VECTOR-REF isn't guaranteed to signal an error if its second argument is
inexact. Section 1.3.2 says "Implementations may extend a procedure's
domain of definition to include such arguments".
Will Clinger:
...e.g. (MAX 1.4 #e1e100) ==> 9.999999999999998e99.
Bill Rozas:
As far as I understand it (and GJS agrees with me), the example Will
shows could only be correct in an implementation where
(>= 9.999999999999998e99 #e1e100) is true. If it isn't, the
implementation of MAX/SUP is in error.
Not as I understand it. I intended for this example to illustrate
what happens in an implementation that uses IEEE 64-bit floating
point to represent inexact reals, but I goofed (because of a bug
in the least significant bit of MacScheme's implementation of
EXACT->INEXACT for large numbers). A better example is
(MAX 1.4 #e1e200) ==> 9.99999999999999969733e199
I think this example is correct in the implementation described, even
though (>= 9.99999999999999969733e199 #e1e200) is false. The entire
specification of MAX and MIN is that they "return the maximum or minimum
of their arguments", but the implementation described will be unable to
meet this spec because it doesn't have enough precision to represent
10↑200 as an inexact number without loss of accuracy. The implementation
has exactly the same problem with + and *, which are supposed to "return
the sum or product of their arguments" but can't in examples like
(+ 1.5 1e-30). In such cases "it is the duty of each implementation
to make the result as close as practical to the mathematically
ideal result". It happens that 9.99999999999999969733e199 is the
inexact number that is closest to 10↑200 in this implementation.
The next closest inexact number is 1.00000000000000013969e200,
which is apparently the result desired by Rozas and GJS:
...A good implementation would coerce to floating point
rounding towards infinity (ie. add 1 at the least significant
mantissa bit after truncating the bits) in order to return a
value >= than all the inputs.
This isn't obvious, and I think it's untrue. The property you
desire (that the result be greater than or equal to all inputs)
is in conflict with another nice property, namely that the result
of MAX be as close as possible to the mathematically ideal result.
Something has to give.
I think that requiring MAX to round up would be like requiring
(+ x y) to return a number greater than x whenever y is positive.
It sounds plausible at first, but would tend to make computations
less accurate. I have to admit, given the difficulty of coming up
with any real-world examples where MAX returns a value that is not
equal to one of its arguments, that a difference in the least
significant bit in such cases would probably be of very little
consequence, and it might make someone's mother happy.
Jim Miller:
(a) They are selectors from a set of numbers and thus there is
a legitimate expectation that (memq (max <set>) <set>) ==>
#t. (Yes, I DO mean memq not memv.)
I think you should have meant MEMV, not MEMQ. There is only one reason
why EQ? is in Scheme at all: it is an efficiency hack for performing an
EQV? comparison when one of the arguments is known to be of a type for
which EQ? coincides with EQV?. Consider these facts: The EQ? procedure
is nothing but a more implementation-dependent version of EQV?. It is
perfectly legal for an implementation to make EQ? be exactly the same
procedure as EQV?. It is also legal for EQ? to return #F whenever it is
passed a number or a character. EQ? is, in short, a real crock whose
role we should be eliminating rather than expanding.
(The fact that EQ? is permitted to be universally false when passed a
number or character would not be affected by the R3.99RS's new requirement
that EQV?-ness must be preserved by storing and fetching from data
structures. Strengthening this to preservation of EQ?-ness would decrease
the performance of some Scheme implementations, which could only be
justified by some offsetting benefit. The efficiency argument against
preserving EQ?-ness cannot simply be dismissed, because efficiency is also
the only argument in favor of having EQ? in the language. The only
important objects for which EQ? can differ from EQV? are numbers,
characters, and empty strings and vectors, so any benefits obtained from
preserving EQ?-ness as well as EQV?-ness must turn on the desirability
of making EQ? more reliable on these objects. It will be hard to argue
that EQ? needs to be more reliable on these objects, because anyone who
thinks they need the additional reliability could just use EQV? instead.)
Guy Steele Jr:
....maybe inexact numbers should not possess object identity.
The behavior of EQ? on numbers (exact or inexact) is unspecified,
except that it must always return a boolean and (EQ? x y) implies
(EQV? x y). The behavior of EQV? on numbers is defined in terms
of = and EXACT?. It therefore seems to me that Scheme numbers in
general already lack object identity, unless what you mean by that
is either (1) you want calling EQ? or EQV? on an inexact number to
be an error; or (2) you want the Scheme procedure = to be unspecified
or erroneous on inexact numbers.
Alan Bawden:
....I am a believer in object identity even for inexact numbers....
I haven't the slightest idea what you are talking about, and it makes
me feel like Michael Dukakis. Could somebody please tell me what
object identity is, and why it inspires such passionate allegiance?
Jim Miller:
(e) None of the above. Please state your position.
See page 33 of "'Toons for our Times" by Berke Breathed.
Peace, Will
∂07-Aug-89 2206 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu LIST?
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Aug 89 22:06:15 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AB02881; Tue, 8 Aug 89 00:55:06 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21779;
7 Aug 89 21:00 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 7 Aug 89 21:00:49 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21713;
7 Aug 89 20:53 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA00782; Mon, 7 Aug 89 20:52:54 EDT
Received: from localhost by zurich.ai.mit.edu; Mon, 7 Aug 89 20:49:35 edt
Date: Mon, 7 Aug 89 20:49:35 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8908080049.AA00201@zurich.ai.mit.edu>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Mon, 7 Aug 89 17:01:02 PDT <8908080001.AA04985@spencer.cs.uoregon.edu>
Subject: LIST?
Date: Mon, 7 Aug 89 17:01:02 PDT
From: will@cs.uoregon.edu
I will add LIST? to the R3.99RS and R4RS as an essential procedure provided
the authors will join me in a rousing chorus of "YES, YES!".
Yes.
∂07-Aug-89 2216 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com LIST?
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Aug 89 22:15:41 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02909; Tue, 8 Aug 89 01:00:55 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id ab21998;
7 Aug 89 21:17 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 7 Aug 89 21:18:10 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21817;
7 Aug 89 21:06 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00924; Mon, 7 Aug 89 21:06:44 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Mon, 7 Aug 89 21:03:22 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA01112; Mon, 7 Aug 89 18:06:26 pdt
Message-Id: <8908080106.AA01112@sde.hp.com>
Received: by hpesogg; Mon, 7 Aug 89 18:05:48 pdt
Date: Mon, 7 Aug 89 18:05:48 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Mon, 7 Aug 89 17:01:02 PDT <8908080001.AA04985@spencer.cs.uoregon.edu>
Subject: LIST?
Reply-To: jinx%hpesogg@sde.hp.com
I will add LIST? to the R3.99RS and R4RS as an essential procedure provided
the authors will join me in a rousing chorus of "YES, YES!". Proposed
wording:
(LIST? obj) essential procedure
List? returns #t if obj is a list of finite length, and otherwise
returns #f.
(list '(a b c)) ==> #t
(list '()) ==> #t
(list '(a . b)) ==> #f
(let ((x (list 'a)))
(set-cdr! x x)
(list? x)) ==> #f
(let loop ()
(newline)
(display "Yes, Yes!")
(loop))
∂07-Aug-89 2237 cph@zurich.ai.mit.edu Scheme Digest #174
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Aug 89 22:37:18 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA02907; Tue, 8 Aug 89 01:00:27 EDT
Received: from localhost by zurich.ai.mit.edu; Tue, 8 Aug 89 00:57:09 edt
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Sender: cph@zurich.ai.mit.edu
To: scheme-inbox@life.ai.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id: <8908070017.aa10696@mintaka.lcs.mit.edu>
Date: 7 AUG 89 00:02:32 EDT
Subject: Scheme Digest #174
Scheme Digest #174 7 AUG 89 00:02:32 EDT
Today's Topics:
"Scheme has data types and Lisp doesn't."
----------------------------------------------------------------------
Date: 6 Aug 89 18:55:51 GMT
From: Bruce Smith <thorin!evergreen!bts@mcnc.org>
Subject: Re: "Scheme has data types and Lisp doesn't."
Message-Id: <9085@thorin.cs.unc.edu>
I hope someone here can explain the origin of this notion that
"Scheme has data types and Lisp doesn't". I have heard several
people make this claim over the past couple of years, but never
with any concrete evidence nor even a clear explanation of what
it's supposed to mean. (It was usually in almost exactly those
words, however.)
I know a modest amount about these languages and have access to
references on them. I have not been able figure out what it is
supposed to mean.
Most recently, in a discussion of which functional programming
language should be taught to students (not at UNC, by the way)
I heard that Scheme was to be preferred because compiled Scheme
executes much faster than compiled Common Lisp. The reason for
that difference? Because, of course, "Scheme has data types
and Lisp doesn't."
------------------------------
End of Scheme Digest
********************
∂08-Aug-89 0015 @mc.lcs.mit.edu,@zermatt.lcs.mit.edu:ziggy@hx.lcs.mit.edu RE: sequential evaluation of arguments
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Aug 89 00:15:22 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00254; Tue, 8 Aug 89 02:59:21 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22442;
7 Aug 89 22:03 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 7 Aug 89 22:03:25 EDT
Received: from HX.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 280341; 7 Aug 89 22:03:14 EDT
Received: by hx.LCS.MIT.EDU (5.51/4.7); Mon, 7 Aug 89 22:01:54 EDT
Message-Id: <2827533780-14096492@RTS-8>
Sender: ziggy@rts-8.lcs.mit.edu
Date: Mon, 7 Aug 89 22:03:00 EDT
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
To: rrrs-authors@zermatt.lcs.mit.edu
Subject: RE: sequential evaluation of arguments
Note: Although the precise order of evaluation is unspecified, the
expressions must be evaluated without interleaving. Interleaving is
not allowed because Scheme provides no facilities for serializing
concurrent side effects.
Isn't this a bit strong? Specifically, saying that exprs MUST BE EVALUATED
WITHOUT INTERLEAVING precludes parallel implementations which do compile-time
side-effect analysis to determine that two expressions' side effects are
non-interferring and thus can safely be run concurrently. (Note that within
this context, we would consider two calls to CONS to "interfere" in the sense
that they have ALLOCATE effects, the results of which may not be shared, just
as we would consider two calls to I/O routines on the same I/O port to
interfere).
A more forgiving wording might be "expressions must be evaluated without
DETECTABLE interleaving" or "expressions must be evaluated in an order
consistent with some non-interleaved evaluation. Detectable interleaving is
not allowed because Scheme provides no facilities for serializing concurrent
interferring side-effects." I emphasize interferrence since that is the real
concern: one shouldn't care about serializing non-interferring side-effects.
To point, it would be nice to allow common sub-expression ellimination of
pure expressions, such as:
(let* ((x (f (moby-expensive-number-crunch 3.1415)))
(y (g (moby-expensive-number-crunch 3.1415))))
(h x y))
==
(let* (($$ (moby-expensive-number-crunch 3.1415))
(x (f $$))
(y (g $$)))
(h x y))
My understanding of the Note at the top is that this would be forbidden.
It would be a shame to banish "sufficiently clever" compilers for parallel
machines to the realm of non-Scheme.
Am I just being an alarmist? ~Ziggy
∂08-Aug-89 0241 @mc.lcs.mit.edu,@zermatt.lcs.mit.edu:jinx@hpesogg.hp.com sequential evaluation of arguments
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Aug 89 02:41:44 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00786; Tue, 8 Aug 89 05:29:45 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26224;
8 Aug 89 3:55 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 8 Aug 89 03:56:20 EDT
Received: from SDE.HP.COM by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 280383; 8 Aug 89 03:56:07 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA15625; Tue, 8 Aug 89 00:54:59 pdt
Message-Id: <8908080754.AA15625@sde.hp.com>
Received: by hpesogg; Tue, 8 Aug 89 00:54:21 pdt
Date: Tue, 8 Aug 89 00:54:21 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: ziggy@hx.lcs.mit.edu
Cc: rrrs-authors@zermatt.lcs.mit.edu
In-Reply-To: "Michael R. Blair"'s message of Mon, 7 Aug 89 22:03:00 EDT <2827533780-14096492@RTS-8>
Subject: sequential evaluation of arguments
Reply-To: jinx%hpesogg@sde.hp.com
Note: Although the precise order of evaluation is unspecified, the
expressions must be evaluated without interleaving. Interleaving is
not allowed because Scheme provides no facilities for serializing
concurrent side effects.
Isn't this a bit strong? Specifically, saying that exprs MUST BE EVALUATED
WITHOUT INTERLEAVING precludes parallel implementations which do compile-time
side-effect analysis to determine that two expressions' side effects are
non-interferring and thus can safely be run concurrently. (Note that within
this context, we would consider two calls to CONS to "interfere" in the sense
that they have ALLOCATE effects, the results of which may not be shared, just
as we would consider two calls to I/O routines on the same I/O port to
interfere).
Being a firm believer in Quantum Mechanics, I believe that if you
can't tell the difference, you can do anything you want. I think you
are interpreting the wording too restrictively. I interpret all such
"commands" as saying "your implementation must produce the same values
as if...", not "your implementation must act in exactly the following
way...".
∂08-Aug-89 0258 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #175
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Aug 89 02:58:11 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00783; Tue, 8 Aug 89 05:25:21 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa23540;
8 Aug 89 0:06 EDT
Date: 8 AUG 89 00:04:08 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Subject: Scheme Digest #175
To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id: <8908080006.aa23540@mintaka.lcs.mit.edu>
Scheme Digest #175 8 AUG 89 00:04:08 EDT
Today's Topics:
Opinions wanted.
----------------------------------------------------------------------
Date: 7 Aug 89 13:35:43 GMT
From: "Mark W. Bailey" <haven!uvaarpa!virginia!uvacs!mwb5y@purdue.edu>
Subject: Opinions wanted.
Message-Id: <MWB5Y.89Aug7093543@hopper.hopper.cs.virginia.edu>
We looking for a good book on Scheme to use in a graduate programming
languages course. I've found "The SCHEME programming language"
by Dybvig, but I don't have access to a copy. I'd like information
on this or any other books that are available.
Please send e-mail.
Mark W. Bailey mwb5y@virginia.edu
Computer Science
University of Virginia
------------------------------
End of Scheme Digest
********************
∂08-Aug-89 1701 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu R3.99RS issues (else)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Aug 89 17:01:40 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA06814; Tue, 8 Aug 89 19:47:24 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00126;
8 Aug 89 11:01 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Aug 89 11:01:32 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa29950;
8 Aug 89 10:56 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02346; Tue, 8 Aug 89 10:55:58 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Tue, 8 Aug 89 10:52:36 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA03048; Tue, 8 Aug 89 07:55:06 PDT
Date: Tue, 8 Aug 89 07:55:06 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8908081455.AA03048@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Mon, 7 Aug 89 17:02:53 PDT <8908080002.AA05003@spencer.cs.uoregon.edu>
Subject: R3.99RS issues (else)
ciao,
I think that Morry's argument is valid. If a user wants to use 'else' in the
cond or case special forms define the variable to be #t. This seems like a
clear example of where we can reduce the number of things the user has to
remember without screwing anyone!
I personally would like to see the language only grow with additional concepts.
(peace chance)
mas
∂08-Aug-89 1733 @mc.lcs.mit.edu,@life.ai.mit.edu:hudak-paul@yale.edu Re: sequential order of evaluation
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Aug 89 17:33:45 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA07002; Tue, 8 Aug 89 20:19:17 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00428;
8 Aug 89 11:31 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Aug 89 11:32:01 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa00398;
8 Aug 89 11:29 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02577; Tue, 8 Aug 89 11:29:38 EDT
Received: from ATHENA.CS.YALE.EDU ([128.36.0.27]) by zurich.ai.mit.edu; Tue, 8 Aug 89 11:26:15 edt
Received: by ATHENA.CS.YALE.EDU; Tue, 8 Aug 89 10:07:46 EDT
From: Paul Hudak <hudak-paul@yale.edu>
Message-Id: <8908081407.AA09346@ATHENA.CS.YALE.EDU>
Received: by yale-ring (node-add2/ADD2)
via WIMP-MAIL (Version 1.3/1.5) ; Tue Aug 8 09:56:20
Date: Tue, 8 Aug 89 09:56:16 EDT
Subject: Re: sequential order of evaluation
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu, Mon, 7 Aug 89 17:01:45 PDT
The choice is explicit in the rather informal formal semantics, which says
the expressions must be evaluated sequentially in some permuted order.
To be more precise, the informal formal semantics says that whatever
permuted order is chosen must be used for ALL expressions. That bothers
me much more than having it prohibit interleaving.
How do the authors feel about adding the following note to section 4.1.3?
Note: Although the precise order of evaluation is unspecified, the
expressions must be evaluated without interleaving. Interleaving is
not allowed because Scheme provides no facilities for serializing
concurrent side effects.
Completely prohibiting interleaving seems too strong.
To kill two birds with one stone, I think the note should read something like:
Note:
(1) The unspecified order-of-evaluation may be chosen differently for
each expression.
(2) An implementation is only required to guarantee a result that is
consistent with SOME sequential order-of-evaluation (and thus
interleaving is not necessarily prohibited).
-Paul
-------
∂08-Aug-89 1910 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu LIST?
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Aug 89 19:09:45 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA07634; Tue, 8 Aug 89 21:57:25 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00515;
8 Aug 89 11:37 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Aug 89 11:38:19 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa00440;
8 Aug 89 11:32 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02590; Tue, 8 Aug 89 11:32:06 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Tue, 8 Aug 89 11:28:43 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA03174; Tue, 8 Aug 89 08:30:53 PDT
Date: Tue, 8 Aug 89 08:30:53 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8908081530.AA03174@sesame.Stanford.EDU>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Mon, 7 Aug 89 17:01:02 PDT <8908080001.AA04985@spencer.cs.uoregon.edu>
Subject: LIST?
LIST? YES, YES!
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂08-Aug-89 2158 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu sequential order of evaluation
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Aug 89 21:58:27 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA09413; Wed, 9 Aug 89 00:48:56 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00627;
8 Aug 89 11:44 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Aug 89 11:45:10 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa00579;
8 Aug 89 11:42 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02692; Tue, 8 Aug 89 11:42:13 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Tue, 8 Aug 89 11:38:49 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA03202; Tue, 8 Aug 89 08:41:03 PDT
Date: Tue, 8 Aug 89 08:41:03 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8908081541.AA03202@sesame.Stanford.EDU>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Mon, 7 Aug 89 17:01:45 PDT <8908080001.AA04992@spencer.cs.uoregon.edu>
Subject: sequential order of evaluation
Date: Mon, 7 Aug 89 17:01:45 PDT
From: will@cs.uoregon.edu
How do the authors feel about adding the following note to section 4.1.3?
Note: Although the precise order of evaluation is unspecified, the
expressions must be evaluated without interleaving. Interleaving is
not allowed because Scheme provides no facilities for serializing
concurrent side effects.
I find the above opaque and would like to suggest the following alternative
which uses the concept os SERIALIZABILITY as established in the database
literature.
Note: Although the precise order of evaluation is unspecified, the evaluation
of the expressions must be "serializable". An evaluation ordering is said to
be serializable if its effects are indistinguishable from those of some
sequential evaluation of the expressions. Interleaved evaluation of several
expresions is ONLY valid if the effects of interleaving are serializable (i.e.
undetectable).
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂08-Aug-89 2334 @mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:RPG@sail.stanford.edu re: sequential evaluation of arguments
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Aug 89 23:34:30 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA09769; Wed, 9 Aug 89 02:24:12 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00821;
8 Aug 89 12:02 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 8 Aug 89 12:03:00 EDT
Received: from SAIL.STANFORD.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 280467; 8 Aug 89 12:02:48 EDT
Message-Id: <NJ7jX@SAIL.Stanford.EDU>
Date: 08 Aug 89 0900 PDT
From: Dick Gabriel <RPG@sail.stanford.edu>
Subject: re: sequential evaluation of arguments
To: jinx%hpesogg@sde.hp.com, ziggy@hx.lcs.mit.edu
Cc: rrrs-authors@zermatt.lcs.mit.edu
[In reply to message from jinx%hpesogg@sde.hp.com sent Tue, 8 Aug 89 00:54:21 pdt.]
Jinx writes:
Being a firm believer in Quantum Mechanics, I believe that if you
can't tell the difference, you can do anything you want. I think you
are interpreting the wording too restrictively. I interpret all such
"commands" as saying "your implementation must produce the same values
as if...", not "your implementation must act in exactly the following
way...".
Perhaps a clear statement of this should be placed at the front of the
document so that those who don't understand Quantum Mechanics can understand
Scheme.
-rpg-
∂09-Aug-89 0009 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu R3.99RS issues (macros in R4RS)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Aug 89 00:09:34 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00245; Wed, 9 Aug 89 02:58:30 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01606;
8 Aug 89 13:03 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Aug 89 13:04:00 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa01536;
8 Aug 89 12:57 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03353; Tue, 8 Aug 89 12:57:18 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Tue, 8 Aug 89 12:53:56 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA03492; Tue, 8 Aug 89 09:56:26 PDT
Date: Tue, 8 Aug 89 09:56:26 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8908081656.AA03492@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Mon, 7 Aug 89 17:02:53 PDT <8908080002.AA05003@spencer.cs.uoregon.edu>
Subject: R3.99RS issues (macros in R4RS)
ciao,
Will>The plan is for the R4RS (but not the R3.99RS) will have an appendix that
Will>describes (at least) two incompatible macro proposals and the issues that
Will>have prevented them from being resolved; this should be the only
Will>substantial difference between the R3.99RS and the R4RS.
I am in strong disagreement with the inclusion of two appendices, as the net
effect will be an unfair evaluation of the issues by the user community.
Syntactic closures without a user interface will not be 'user friendly', but I
believe addresses the issues that are important. Extend-syntax has many nice
properties, but does NOT address the issues that are important to me. I can
not believe that a compromise is not attainable by the macro committee. I
implore the committee and other interested parties to resolve this divisive
issue.
To make the point totally clear I believe that R4RS should NOT be issued until
this issue is resolved with ONE decision.
(peace chance)
mas
∂09-Aug-89 0012 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@ZERMATT.lcs.mit.edu:ziggy@hx.lcs.mit.edu RE: evaluation order rule
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Aug 89 00:12:08 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00276; Wed, 9 Aug 89 03:03:34 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05380;
8 Aug 89 17:34 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Aug 89 17:30:32 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa05246;
8 Aug 89 17:27 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA05808; Tue, 8 Aug 89 17:25:59 EDT
Received: from ZERMATT.LCS.MIT.EDU (zermatt.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 8 Aug 89 17:22:41 edt
Received: from HX.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 280559; 8 Aug 89 17:25:18 EDT
Received: by hx.LCS.MIT.EDU (5.51/4.7); Tue, 8 Aug 89 17:23:54 EDT
Message-Id: <2827603503-1770121@RTS-8>
Sender: ziggy@rts-8.lcs.mit.edu
Date: Tue, 8 Aug 89 17:25:03 EDT
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
To: jinx%zurich.ai.mit.edu@zermatt.ai.mit.edu
Cc: rrrs-authors%zurich.ai.mit.edu@zermatt.ai.mit.edu
Subject: RE: evaluation order rule
As per Jinx's reply:
[paraphrase]: Breaking a rule is only illegal if someone sees you do it.
Thanks. I had hoped I was just being too literal... I get nervous when I
hear ``thou shalt not''. In this case it seems no big deal, but I worry about
restrictions that may be too strong.
Take for example the Anti-Aliasing Rule in Gifford & Lucassen's FX language:
it is intended to forbid undetected interferrence but it is worded to forbid
run-time detection&serialization of potentially interferring concurrent
threads (it forces them to signal an error instead). Thus, stating a design
desiderata as a restriction without carefully stating the principle behind it,
although expedient, can be a precarious business. [I believe the FX designers
intend to fix this deficiency in the next version of their language.]
The evaluation rule as originally stated was careful to explain the lack of
serializing facilities in Scheme as the problem but it did so as a
rationalization for forbidding non-interleaving. I had hoped that merely
adding the adjective DETECTABLE would be judicious and non-offensive.
Whatever. Guess I just don't like rules.
~Ziggy
∂09-Aug-89 0148 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: R3.99RS issues (else)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Aug 89 01:47:44 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00691; Wed, 9 Aug 89 04:36:08 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07319;
8 Aug 89 20:29 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Aug 89 20:29:07 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07293;
8 Aug 89 20:24 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07031; Tue, 8 Aug 89 20:24:17 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Tue, 8 Aug 89 20:20:58 edt
Received: from Semillon.ms by ArpaGateway.ms ; 08 AUG 89 17:19:47 PDT
Date: Tue, 08 Aug 89 17:19:50 PDT
From: Pavel.pa@xerox.com
Subject: Re: R3.99RS issues (else)
In-Reply-To: <8908081455.AA03048@sesame.Stanford.EDU>
To: Mike Shaff <shaff@sesame.stanford.edu>
Cc: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890808-171947-2772@Xerox>
Defining ``else'' to be #t in not sufficient to allow users to use the
``else'' keyword in case-expressions, since that position in the form is
not evaluated.
I see no reason to use #t as the ``otherwise'' clause marker in a
case-expression. It has no more semantic justification than, say, 17. The
right name for that spot is ``else''.
Pavel
∂09-Aug-89 0355 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Dynamic variables
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Aug 89 03:55:37 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01177; Wed, 9 Aug 89 06:41:50 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07634;
8 Aug 89 20:53 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Aug 89 20:53:25 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07597;
8 Aug 89 20:50 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07222; Tue, 8 Aug 89 20:50:29 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Tue, 8 Aug 89 20:47:08 edt
Received: from Semillon.ms by ArpaGateway.ms ; 08 AUG 89 17:48:10 PDT
Date: Tue, 08 Aug 89 17:48:10 PDT
From: Pavel.pa@xerox.com
Subject: Dynamic variables
To: RRRS-Authors@zurich.ai.mit.edu
Cc: Pavel.pa@xerox.com
Message-Id: <890808-174810-2879@Xerox>
This is the proposal for adding dynamic variables (aka fluid binding) to
Scheme, as approved by consensus at the first meeting of BASH. See my
message of 05 Jul 89 for the details of the motivations behind the
proposal.
We propose adding four procedures and one derived expression type to
Scheme:
(MAKE-DYNAMIC obj) [Procedure]
Create and return a new ``dynamic variable'' whose global value is obj.
(DYNAMIC-REF dvar) [Procedure]
Return the value of the given dynamic variable in the current dynamic
environment.
(DYNAMIC-SET! dvar obj) [Procedure]
Change the value of the given dynamic variable to obj in the current
dynamic environment. The returned value is unspecified.
(CALL-WITH-DYNAMIC-BINDING dvar obj thunk) [Procedure]
Invoke and return the value of the given thunk in a new, nested dynamic
environment in which the given dynamic variable has been bound to a new
location whose initial contents are the value obj. This dynamic
environment has precisely the same extent as the invocation of the thunk
and is thus captured by continuations created within that invocation and
re-established by those continuations when they are invoked.
(DYNAMIC-BIND ((var-expr val-expr) ...) . body) [Syntax]
Evaluates the var-exprs and val-exprs in an unspecified order; the
var-exprs should yield dynamic variables. Returns the result of evaluating
the body in a new, nested dynamic environment in which the given dynamic
variables have new bindings, initialized to the given values. This dynamic
environment has precisely the same extent as the evaluation of the body and
is thus captured by continuations created within the body and
re-established by those continuations on invocation.
The DYNAMIC-BIND derived expression type has the following rewrite rule:
(dynamic-bind ((<var-expr1> <val-expr1>)
(<var-expr2> <val-expr2>)
...
(<var-exprN> <val-exprN>))
. <body>)
is equivalent to
(let ((var1 <var-expr1>)
(val1 <val-expr1>)
(var2 <var-expr2>)
(val2 <val-expr2>)
...
(varN <var-exprN>)
(valN <val-exprN>)
(body-thunk (lambda () . <body>)))
(call-with-dynamic-binding var1 val1
(lambda ()
(call-with-dynamic-binding var2 val2
(lambda ()
...
(call-with-dynamic-binding varN valN
body-thunk) ... )))))
====================================================================
Some notes on this proposal:
-- I think that the ``call-with-dynamic-binding'' procedure was actually
named ``call-with-dynamic'' in the proposal passed by BASH, but that
sounded funny to me. I'm willing to change it back, though, if anyone
objects to my changing it.
-- Should there be a ``dynamic?'' predicate that is true only of dynamic
variables? I'm inclined to think so.
-- Should it be specified that dynamic variables are a new data type,
disjoint from the others? I'm again so inclined.
-- Given ``dynamic-wind'', a portable shallow-binding implementation of the
proposal can be written for all single-processor implementations of Scheme.
It was suggested at the BASH meeting that something like this be done and
placed in the library. As stated in earlier messages, multiprocessor
implementations will have to implement it more primitively; Jinx has
pointed out, however, that two simple procedures for accessing the
process-specific dynamic environment suffice.
-- This proposal does not specify whether or not
``call-with-dynamic-binding'' tail-calls the given thunk. I think this is
proper. It is possible for deep-binding implementations to use tail-call,
but only at the expense of passing the dynamic environment on every
procedure call. In shallow binding implementations, it is probably not
possible at all.
Pavel
∂09-Aug-89 0440 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com sequential order of evaluation
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Aug 89 04:40:09 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01352; Wed, 9 Aug 89 07:28:52 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa08015;
8 Aug 89 21:32 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Aug 89 21:16:52 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07815;
8 Aug 89 21:13 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07317; Tue, 8 Aug 89 21:12:49 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Tue, 8 Aug 89 21:09:30 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA05770; Tue, 8 Aug 89 18:11:48 pdt
Message-Id: <8908090111.AA05770@sde.hp.com>
Received: by hpesogg; Tue, 8 Aug 89 18:11:13 pdt
Date: Tue, 8 Aug 89 18:11:13 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: hudak-paul@yale.edu
Cc: will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Paul Hudak's message of Tue, 8 Aug 89 09:56:16 EDT <8908081407.AA09346@ATHENA.CS.YALE.EDU>
Subject: sequential order of evaluation
Reply-To: jinx%hpesogg@sde.hp.com
To kill two birds with one stone, I think the note should read something like:
Note:
(1) The unspecified order-of-evaluation may be chosen differently for
each expression.
(2) An implementation is only required to guarantee a result that is
consistent with SOME sequential order-of-evaluation (and thus
interleaving is not necessarily prohibited).
This may still be too restrictive. It seems to me that it should be
allowable to choose a different sequential order each time an
expression is evaluated, rather than choosing an order per expression.
Admittedly this will be rare because of implementation problems, but
it should not be disallowed.
∂09-Aug-89 0657 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com MIN and MAX (long message)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Aug 89 06:57:22 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01948; Wed, 9 Aug 89 09:40:58 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa08093;
8 Aug 89 21:40 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Aug 89 21:41:13 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa08043;
8 Aug 89 21:36 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07396; Tue, 8 Aug 89 21:23:46 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Tue, 8 Aug 89 21:20:23 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA06014; Tue, 8 Aug 89 18:23:01 pdt
Message-Id: <8908090123.AA06014@sde.hp.com>
Received: by hpesogg; Tue, 8 Aug 89 18:22:26 pdt
Date: Tue, 8 Aug 89 18:22:26 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Mon, 7 Aug 89 16:02:42 PDT <8908072302.AA04327@spencer.cs.uoregon.edu>
Subject: MIN and MAX (long message)
Reply-To: jinx%hpesogg@sde.hp.com
Bill Rozas:
As far as I understand it (and GJS agrees with me), the example Will
shows could only be correct in an implementation where
(>= 9.999999999999998e99 #e1e100) is true. If it isn't, the
implementation of MAX/SUP is in error.
Not as I understand it. I intended for this example to illustrate
what happens in an implementation that uses IEEE 64-bit floating
point to represent inexact reals, but I goofed (because of a bug
in the least significant bit of MacScheme's implementation of
EXACT->INEXACT for large numbers). A better example is
(MAX 1.4 #e1e200) ==> 9.99999999999999969733e199
The problem with this is that
(MAX 9.99999999999999969733e199 #e1e200) ==> 9.99999999999999969733e199
while the implementation can still distinguish (in the sense of < and
>) between both arguments.
This seems wrong!
I think that requiring MAX to round up would be like requiring
(+ x y) to return a number greater than x whenever y is positive.
It sounds plausible at first, but would tend to make computations
less accurate. I have to admit, given the difficulty of coming up
with any real-world examples where MAX returns a value that is not
equal to one of its arguments, that a difference in the least
significant bit in such cases would probably be of very little
consequence, and it might make someone's mother happy.
I think your analogy is pushing it a bit. I don't expect inexact + to
follow any particular ordering properties. In fact, we know that
floating point addition (the "usual" implementation) rounds towards
even, and there are (or so I'm told) good reasons for this. I do
expect some ordering properties out of MAX/SUP, however. Otherwise I
would not be using it at all. The rule that GJS and I like, namely
that MAX/SUP should return the smallest value >= all of its arguments,
makes it more predictable than yours.
∂09-Aug-89 1545 @mc.lcs.mit.edu,@life.ai.mit.edu:bartlett@decwrl.dec.com First BASH Meeting
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Aug 89 15:44:46 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA06463; Wed, 9 Aug 89 18:25:51 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01511;
8 Aug 89 12:55 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Aug 89 12:50:51 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa01371;
8 Aug 89 12:41 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02485; Tue, 8 Aug 89 11:13:44 EDT
Received: from decwrl.dec.com (decwrl.dec.com) by zurich.ai.mit.edu; Tue, 8 Aug 89 11:10:19 edt
Received: from gnomec.pa.dec.com by decwrl.dec.com (5.54.5/4.7.34)
id AA00220; Tue, 8 Aug 89 08:13:31 PDT
Received: from gnomec.pa.dec.com by decwrl.dec.com (5.54.5/4.7.34)
for rrrs-authors@zurich.ai.mit.edu; id AA00220; Tue, 8 Aug 89 08:13:31 PDT
Received: by gnomec.pa.dec.com (5.57/4.7.34)
id AA02503; Tue, 8 Aug 89 08:00:51 PDT
Date: Tue, 8 Aug 89 08:00:51 PDT
From: Joel Bartlett <bartlett@decwrl.dec.com>
Message-Id: <8908081500.AA02503@gnomec.pa.dec.com>
To: bartlett@decwrl.dec.com, rrrs-authors@zurich.ai.mit.edu
Subject: First BASH Meeting
First BASH Meeting
Bay Area Scheme Hackers (BASH) is dedicated to fostering informal
communication among those interested in the programming language Scheme in
the San Francisco Bay Area. Details to follow after we get organized.
Minutes:
The first meeting was held at Stanford on 1 August 1989 with Daniel Weise
graciously providing a place to meet and lunch. Those in attendance were:
Daniel Weise daniel@mojave.stanford.edu
Michael Shaff shaff@sesame.stanford.edu
Guillermo Rozas jinx@zurich.ai.mit.edu
Morry Katz katz@polya.stanford.edu
James O'Toole james@zermatt.lcs.mit.edu
Pierre Jouvelot jouvelot@brokaw.lcs.mit.edu
James Rauen rauen.pa@xerox.com
Pavel Curtis pavel.pa@xerox.com
Michael Plass plass.pa@xerox.com
Erik Ruf ruf@dolores.stanford.edu
Jonathan Rees jar@zurich.ai.mit.edu
Joel Bartlett bartlett@decwrl.dec.com
Following the drafting of a scribe, the first order of business was a
discussion of rrrs-authors issues.
MAX/MIN/SUP/INF
Resolved: these words may not be used in any conversation during the
meeting.
Uniform definition syntax
Pavel spoke in favor of his earlier proposal to rrrs-authors on 22 jun 89:
I'd like to request that the syntax and semantics of bodies and programs
be identical, but not quite like either one in R3RS. Let the syntax be
<program> ::= { <expression> | <definition> | (begin <program>) }*
<definition> ::= (define <variable> <expression>)
| (define (<variable> <def formals>) <body>)
<body> ::= <program>
so definitions and expressions can be freely mixed, both at ``top level''
and internally. Also, BEGINs at top level need not consist entirely of
definitions or entirely of expressions, as in R3.95RS. The semantics is
as follows:
-- (begin <program>) is entirely equivalent to <program> .
-- programs comprising only expressions and definitions have the same
meaning as given in the formal semantics in R3.95RS; that is, bindings
are established for all defined variables giving them unspecified
values after which the program is evaluated in sequence, treating
definitions as if they were assignments.
Jinx spoke in favor of the status quo, i.e. the incremental nature of top
level expression evaluation as noted in section 5.1 of R3RS.
Resolved: no resolution.
Fluid Binding
Pavel discussed his proposal for a fluid binding construct that has been
discussed on rrrs-authors. Objections were made to using the words
"fluid" or "bindings" in the name as they might conflict with existing
fluid constructs. The word "dynamic" was suggested as an alternative.
Resolved: Accept Pavel's constructs with the name changed to dynamic
variables. He will edit his proposal and resubmit to rrrs-authors.
Regularization
Morry was assigned at Snowbird to look into "regularization" of Scheme.
He made a proposal to rrrs-authors on 14 Oct 88.
Resolved: Accept his "non-controversial" recommendations.
Resolved: Accept LIST? as a new predicate. LIST? must always run to
completion, i.e. (LIST? x) => #f, where x is a circular list. Report
should note that lists are a convention, not a primitive data type. It
should also note that the property LIST? of an object may change due to
the effects of SET-CDR!.
Resolved: Without making a value judgement, it is the sense of the
meeting that this is not the time to add additional member functions.
Resolved: Additional control expressions in the style of MAP and FOR-EACH
are desirable, but the group did not muster strong support for any of the
current rrrs-authors proposals.
Resolved: No changes to APPLY.
Multiple Values
Resolved: While not everyone thinks they are a good idea, there is the
feeling that they belong in the language.
Resolved: (values 1) is equivalent to 1.
Resolved: The proposed ARITY procedure reveals too much about the
underlying implementation and should be replaced by a predicate ACCEPTS?
that tests whether a procedure will accept a given number of values. Morry
will change his proposal and resubmit to rrrs-authors.
Modules
Joel described the module system that is in Scheme->C. Scheme->C is
intended to allow Scheme code to coexist with code written in other
languages. The compiler compiles a module at a time. The source for the
module may reside in multiple files and can contain DEFINE-EXTERNAL syntax
for defining variables or procedures in other modules. A variable X that
a module wishes to make visible at the top level has the name X. All
other variables in the module are also visible at the top level with a
name of the form module-name_variable-name. It is an error for two
modules to place the same variable name at the top level.
Jinx described the MIT Scheme package system. MIT Scheme supports multiple
environments, with each package in its own environment. The package
definition is in the form of a "wiring diagram" that unifies variables
across environments. The mechanism also allows procedure integration
information and syntax extensions to be exported.
Pavel described the proposed module Scheme for Scheme Xerox. It will be
based upon Cedar's module system. Each module will have a list of imports
and exports, with an implicit import of the "scheme" interface. Imported
names cannot be assigned. Backdoor for debugging as modules may hide
items (see meta issues). When completed, the definition of the module
system will be posted to rrrs-authors (for information only, not a
proposal for RnRs).
Resolved: no proposals, no resolutions.
Macros
Jonathan reported that there is an impasse between those wanting extend
syntax and those concerned about capture problems. It is not clear how to
resolve this to produce one macro proposal.
Resolved: The macro committee should keep trying. R4RS should not go out
without a macro proposal. It should not go out with two macro proposals.
Records
Much discussion about opaque vs. non-opaque types. In order to satisfy
Jinx and other members of the non-opaque faction, a procedure that maps a
record to its record type descriptor, and some procedure that permits one
to obtain all the selectors from a record type descriptor, will be added
to the proposal.
Resolved: Pavel will update Jonathan's earlier proposal and submit to
rrrs-authors.
Meta Issue - rrrs-authors
How are decisions made? How does a concensus form? Should there be
strong leadership by the editor over the net? A general feeling of
frustration that rrrs-authors discussions don't seem to converge.
Suggestions that might make this happen were to have "someone with
sufficient moral authority" to ride herd on the net, and to require that
proposals contain more information. The example given was Common Lisp
cleanup, where each proposal had to have the problem, the solution, the
cost to users and implementers, plus pros and cons. The proposal is
revised and reissued as new issues come up.
Resolved: it would be nice if rrrs-authors worked better. It may be time
for another rrrs-authors meeting. Perhaps at POPL in San Francisco.
Meta-issue - Timing of RnRS
Proposal: R4RS should hold until there is a macro proposal. While we're
waiting, no other changes should be considered. Instead, new proposals
should be for R5RS.
Resolved: no resolution.
Meta Issue - Opaque vs. non-opaque types
Should the user of a module or record type be allowed to look inside it if
the implementer did not export such an interface? Lively discussion topic!
Resolved: no resolution.
Meta Issue - What is the purpose of the Scheme Report?
(1) To allow us to read each others code, but not constrain
anyone's implementation.
(2) To encourage the construction of common implementations to
allow the exchange of programs.
Another lively discussion topic.
Resolved: no resolution.
After spending most of the day on rrrs-authors issues. The meeting turned
to short presentations about implementations.
Scheme Xerox (Pavel Curtis, Michael Plass, James Rauen)
This implementation is intended to be the upper bound of Scheme and Cedar.
Additions include dynamic variables, macros, modules, strong typing,
concurrency, signals, and monitor locks to Scheme. Signal handling will
be done in a straight forward manner. When a signal occurs, the procedure
that is the value of the dynamic variable *handler* is called with the
signal. It may handle it, or pass it to the previous value of handler.
The project is in the design and specification stage. Implementation
expected to be under way later this year. The system will run on top of
the Portable Common Runtime (threads, garbage collection, dynamic loading,
and name management) that is being done for the port of Cedar to UNIX.
Implementation will be intercallable with Cedar. The intent is to make it
widely available.
Scheme->C (Joel Bartlett)
Scheme->C is a Scheme system designed to generate code that can be
embedded in other systems. The compiler compiles Scheme to C that is then
compiled by the system's C compiler to produce a runnable object. The
system is designed to be very portable with a minimal amount of machine
dependent code in the implementation. Besides the essentials of R3RS (and
many optionals), there are also modules, macros, foreign function calls,
and and an interface to X11's xlib. The system currently runs on VAX and
DECStation 3100 systems. For more details see Scheme Digest #47, #49, and
#63. Currently the licensing is fairly restrictive. This should change
in the near future so that it will be more generally available to
non-commercial users. When this happens, a note will be posted to the
Scheme Digest.
S48 (Jonathan Rees)
A side project to build a Scheme virtual machine. It consists of a byte
code interpreter that has a C and a Scheme implementation. The rest is
coded in Scheme. Seen as a pedagogical tool, but also as a "competitor"
to Xscheme.
Pseudoscheme (Jonathan Rees)
A Scheme to Common Lisp translator that runs in any Common Lisp system.
While it can't completely support call-with-current-continuation and tail
call, it is quite popular.
T (Jonathan Rees)
Waiting for changes from Yale. Would like to modify it so that it comes
up in an R4RS compatible environment. David Kranz has done code
generators for MIPS and SPARC processor architectures.
MIT Scheme (Jinx)
MIT Scheme is done as a tool for courses and research at MIT. While it is
available to others, MIT's needs will direct development. In the process
of shifting from an interpreter based system to a compiler based system.
Compilers are currently available for the VAX and 68020. Future work to
include faster numeric code. For more details see the recent posting to
the Scheme Digest.
The meeting concluded with a few comments on applications.
RPC
Michael Plass is going to be doing an RPC system for Scheme Xerox. It
will allow heterogeneous Scheme implementations with no shared memory to
cooperate.
Library
Jonathan Rees is the new Scheme librarian. He'd like to develop a
strategy to get more stuff into it and publicize it. He'd like to define
standard interfaces and then solicit multiple implementations, some
portable, some not. Some discussion about using Brian Reid's archive
server to handle requests for software.
Resolved: All in favor of the library.
Future BASH meetings
Resolved: We should have more. Pavel to set up a mailing list,
bash↑@xerox.com. Joel suggested that the next meeting could be at WRL
sometime in October. To be further discussed via mail. Speakers,
listeners, etc. needed.
∂10-Aug-89 0646 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu R3.99RS issues (else)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Aug 89 06:46:14 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01851; Thu, 10 Aug 89 09:36:26 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16408;
9 Aug 89 11:42 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 9 Aug 89 11:42:57 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa16386;
9 Aug 89 11:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02926; Wed, 9 Aug 89 11:38:35 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Wed, 9 Aug 89 11:35:13 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA07820; Wed, 9 Aug 89 08:37:41 PDT
Date: Wed, 9 Aug 89 08:37:41 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8908091537.AA07820@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Tue, 08 Aug 89 17:19:50 PDT <890808-171947-2772@Xerox>
Subject: R3.99RS issues (else)
Date: Tue, 08 Aug 89 17:19:50 PDT
From: Pavel.pa@xerox.com
Defining ``else'' to be #t in not sufficient to allow users to use the
``else'' keyword in case-expressions, since that position in the form is
not evaluated.
As was discussed earlier in private mail, ELSE does not have to be a syntactic
keyword for its use in CASE. I advocated removing ELSE as a syntactic keyword,
which only effects COND. In my opinion, it would have been semantically
cleaner if the matching expressions in case were in an evaluated context, but
this is another issue and one which I am sure will never change for historic
reasons, if none other.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂10-Aug-89 0717 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu Dynamic variables
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Aug 89 07:16:44 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02072; Thu, 10 Aug 89 10:05:23 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16493;
9 Aug 89 11:50 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 9 Aug 89 11:50:36 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa16440;
9 Aug 89 11:45 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02979; Wed, 9 Aug 89 11:45:09 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Wed, 9 Aug 89 11:41:37 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA07848; Wed, 9 Aug 89 08:43:47 PDT
Date: Wed, 9 Aug 89 08:43:47 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8908091543.AA07848@sesame.Stanford.EDU>
To: Pavel.pa@xerox.com
Cc: RRRS-Authors@zurich.ai.mit.edu, Pavel.pa@xerox.com
In-Reply-To: Pavel.pa@xerox.com's message of Tue, 08 Aug 89 17:48:10 PDT <890808-174810-2879@Xerox>
Subject: Dynamic variables
Date: Tue, 08 Aug 89 17:48:10 PDT
From: Pavel.pa@xerox.com
This is the proposal for adding dynamic variables (aka fluid binding) to
Scheme, as approved by consensus at the first meeting of BASH. See my
message of 05 Jul 89 for the details of the motivations behind the
proposal.
This proposal was NOT accepted by consensus at BASH as I stated that I was not
comfortable with it at that meeting. Despite the fact that I have corrected
Pavel TWICE on this issue, he insists on using the word consensus in an
effort, I suppose, to give his proposal more weight. I am attempting to
formulate, in my own mind, exactly what about this proposal makes me
uncomfortable and will post a message as soon as I can make a cogent
presentation. In the meantime, however, I wanted to set the record straight.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂10-Aug-89 0725 @mc.lcs.mit.edu,@life.ai.mit.edu:jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk No mail
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Aug 89 07:25:50 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AB02136; Thu, 10 Aug 89 10:13:43 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20679;
9 Aug 89 17:03 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 9 Aug 89 17:03:55 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20636;
9 Aug 89 16:59 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA05921; Wed, 9 Aug 89 16:59:18 EDT
Received: from NSFnet-Relay.AC.UK (nsfnet-relay.ac.uk) by zurich.ai.mit.edu; Wed, 9 Aug 89 16:54:57 edt
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa07324; 9 Aug 89 19:15 BST
Date: Wed, 9 Aug 89 19:21:38 BST
Message-Id: <2090.8908091821@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk>
Subject: No mail
To: rrrs-authors@zurich.ai.mit.edu
Cc: rrrs-authors-request <@uunet.uu.net:rrrs-authors-request@zurich.ai.mit.edu>
I have not seen any mail on this list since the end of July.
What's happened?
∂10-Aug-89 0846 ramsdell@linus.mitre.org Re: First BASH Meeting (Let's meet at POPL)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Aug 89 08:46:14 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02664; Thu, 10 Aug 89 11:29:43 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA03748; Thu, 10 Aug 89 11:30:47 EDT
Posted-Date: Thu, 10 Aug 89 11:24:43 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA00409; Thu, 10 Aug 89 11:24:46 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908101524.AA00409@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Re: First BASH Meeting (Let's meet at POPL)
In-Reply-To: Your message of Tue, 08 Aug 89 08:00:51 -0700.
<8908081500.AA02503@gnomec.pa.dec.com>
Date: Thu, 10 Aug 89 11:24:43 EDT
>> From: Joel Bartlett <bartlett@decwrl.dec.com>
...
>> Bay Area Scheme Hackers (BASH) is dedicated to fostering informal
...
And I thought BASH was GNU's Born Again SHell....
>> Uniform definition syntax
>>
>> Pavel spoke in favor of his earlier proposal to rrrs-authors on 22 jun 89:
>>
>> Jinx spoke in favor of the status quo, i.e. the incremental nature of top
>> level expression evaluation as noted in section 5.1 of R3RS.
I am glad to see the issue get such a hearing. Thanks also to Will
for his explaination of his position. I favor dropping the issue for
consideration for R4RS.
>> Meta Issue - rrrs-authors
>>
...
>> Resolved: it would be nice if rrrs-authors worked better. It may be time
>> for another rrrs-authors meeting. Perhaps at POPL in San Francisco.
I would also like to see another rrrs-authors meeting as long as it is
not an R4RS meeting. I would like to see R4RS out before the end of
this year. R4RS should include name regularization, but if the macros
factions fail to agree, let's drop macros.
There seems to be a fair number of good solid proposals for
consideration in R5RS. Fluid variables and multiple values come
immediately to mind. Maybe we could get some agreement at POPL.
John
∂10-Aug-89 0902 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com R3.99RS issues (macros in R4RS)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Aug 89 08:58:49 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02784; Thu, 10 Aug 89 11:43:17 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20791;
9 Aug 89 17:17 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 9 Aug 89 17:16:40 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20742;
9 Aug 89 17:10 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06002; Wed, 9 Aug 89 17:10:48 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Wed, 9 Aug 89 17:07:29 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA04260; Wed, 9 Aug 89 14:10:30 pdt
Message-Id: <8908092110.AA04260@sde.hp.com>
Received: by hpesogg; Wed, 9 Aug 89 14:09:55 pdt
Date: Wed, 9 Aug 89 14:09:55 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: shaff@sesame.stanford.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Mike Shaff's message of Tue, 8 Aug 89 09:56:26 PDT <8908081656.AA03492@sesame.Stanford.EDU>
Subject: R3.99RS issues (macros in R4RS)
Reply-To: jinx%hpesogg@sde.hp.com
Date: Tue, 8 Aug 89 09:56:26 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
ciao,
Will>The plan is for the R4RS (but not the R3.99RS) will have an appendix that
Will>describes (at least) two incompatible macro proposals and the issues that
Will>have prevented them from being resolved; this should be the only
Will>substantial difference between the R3.99RS and the R4RS.
I am in strong disagreement with the inclusion of two appendices, as the net
effect will be an unfair evaluation of the issues by the user community.
Syntactic closures without a user interface will not be 'user friendly', but I
believe addresses the issues that are important. Extend-syntax has many nice
properties, but does NOT address the issues that are important to me. I can
not believe that a compromise is not attainable by the macro committee. I
implore the committee and other interested parties to resolve this divisive
issue.
To make the point totally clear I believe that R4RS should NOT be issued until
this issue is resolved with ONE decision.
Hear, hear!
∂10-Aug-89 1246 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com Dynamic variables
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Aug 89 12:46:04 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04123; Thu, 10 Aug 89 15:28:53 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02141;
10 Aug 89 11:40 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 10 Aug 89 11:39:47 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa02101;
10 Aug 89 11:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02750; Thu, 10 Aug 89 11:38:00 EDT
Received: from RELAY.CS.NET (relay.cs.net) by zurich.ai.mit.edu; Thu, 10 Aug 89 11:34:32 edt
Received: from tektronix.tek.com by RELAY.CS.NET id aa14063; 10 Aug 89 11:37 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA22625; Thu, 10 Aug 89 08:39:25 PDT
Received: by tekirl.labs.tek.com (5.51/7.1)
id AA06474; Thu, 10 Aug 89 08:35:33 PDT
Received: by tekchips.LABS.TEK.COM (5.51/6.24)
id AA11137; Thu, 10 Aug 89 08:39:47 PDT
Date: Thu, 10 Aug 89 08:39:47 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Message-Id: <8908101539.AA11137@tekchips.LABS.TEK.COM>
To: mkatz%sesame.stanford.edu@relay.cs.net
Cc: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Morris Katz's message of Wed, 9 Aug 89 08:43:47 PDT <8908091543.AA07848@sesame.Stanford.EDU>
Subject: Dynamic variables
I find it bothersome that something called a "variable" can be the
result of an evaluation.
-Norman
∂10-Aug-89 1332 mkatz@sesame.stanford.edu First BASH Meeting (Let's meet at POPL)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Aug 89 13:32:07 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA04678; Thu, 10 Aug 89 16:11:07 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00461; Thu, 10 Aug 89 10:56:41 PDT
Date: Thu, 10 Aug 89 10:56:41 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8908101756.AA00461@sesame.Stanford.EDU>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Thu, 10 Aug 89 11:24:43 EDT <8908101524.AA00409@huxley.mitre.org>
Subject: First BASH Meeting (Let's meet at POPL)
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Posted-Date: Thu, 10 Aug 89 11:24:43 EDT
From: ramsdell@linus.mitre.org
Date: Thu, 10 Aug 89 11:24:43 EDT
>> From: Joel Bartlett <bartlett@decwrl.dec.com>
R4RS should include name regularization, but if the macros
factions fail to agree, let's drop macros.
Lets not drop macros. In my opinion, macros are probably the most important
addition to R3RS which justify creating an R4RS. R4RS without macros is a
quasi-worthless document. How about if we all just agree to come to a decision
on this issue. Sooner or later Scheme must have macros or die.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂10-Aug-89 1625 shaff@sesame.stanford.edu First BASH Meeting (macros)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Aug 89 16:25:44 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA07122; Thu, 10 Aug 89 19:10:35 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00646; Thu, 10 Aug 89 13:41:35 PDT
Date: Thu, 10 Aug 89 13:41:35 PDT
From: shaff@sesame.stanford.edu (Mike Shaff)
Message-Id: <8908102041.AA00646@sesame.Stanford.EDU>
To: rrrs-authors@life.ai.mit.edu
In-Reply-To: Morris Katz's message of Thu, 10 Aug 89 10:56:41 PDT <8908101756.AA00461@sesame.Stanford.EDU>
Subject: First BASH Meeting (macros)
'Give me macros or give me death'
- Macromancer
∂12-Aug-89 0228 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu Re: Dynamic variables
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 12 Aug 89 02:28:22 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00848; Sat, 12 Aug 89 05:14:22 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22338;
11 Aug 89 16:35 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Aug 89 16:31:40 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa22223;
11 Aug 89 16:29 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA20174; Fri, 11 Aug 89 16:29:50 EDT
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Fri, 11 Aug 89 16:26:29 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA05479; Fri, 11 Aug 89 12:53:55 PDT
Received: by spencer.cs.uoregon.edu; Fri, 11 Aug 89 12:53:47 PDT
Date: Fri, 11 Aug 89 12:53:47 PDT
From: will@cs.uoregon.edu
Message-Id: <8908111953.AA08745@spencer.cs.uoregon.edu>
To: Pavel.pa@xerox.com, RRRS-Authors@zurich.ai.mit.edu
Subject: Re: Dynamic variables
Pavel observed that DYNAMIC-WIND sufficed to implement a portable
shallow-binding implementation of the BASH proposal for all
single-processor implementations of Scheme, but claimed that
multiprocessor implementations will have to implement it more
primitively.
I observe that DYNAMIC-WIND suffices to implement a portable
deep-binding implementation of the BASH proposal. It seems to
me that this deep-binding implementation should work for most
multiprocessor implementations as well, provided the "right"
relationship exists between processes and continuations. Some
multiprocessor implementations might want to implement things
more primitively, either for efficiency or because their view
of what is right differs from mine.
Neither the deep-binding nor the shallow-binding implementation
in terms of DYNAMIC-WIND seems capable of supporting a tail-call
semantics for CALL-WITH-DYNAMIC-BINDING.
Peace, Will
∂12-Aug-89 1538 @mc.lcs.mit.edu,@life.ai.mit.edu:danvy@gang-of-four.stanford.edu Re: Dynamic variables
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 12 Aug 89 15:38:25 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04664; Sat, 12 Aug 89 18:18:59 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04565;
12 Aug 89 15:13 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Aug 89 15:13:44 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa04545;
12 Aug 89 15:08 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03649; Sat, 12 Aug 89 15:08:01 EDT
Received: from gang-of-four.Stanford.EDU (gang-of-four.stanford.edu) by zurich.ai.mit.edu; Sat, 12 Aug 89 15:04:43 edt
Received: by gang-of-four.Stanford.EDU (5.0/25-eef) id AA12068; Sat, 12 Aug 89 12:07:33 PDT
Date: Sat, 12 Aug 89 12:07:33 PDT
From: Olivier Danvy <danvy@gang-of-four.stanford.edu>
Message-Id: <8908121907.AA12068@gang-of-four.Stanford.EDU>
To: will@cs.uoregon.edu
Subject: Re: Dynamic variables
Cc: RRRS-Authors@zurich.ai.mit.edu
Will>Neither the deep-binding nor the shallow-binding implementation
Will>in terms of DYNAMIC-WIND seems capable of supporting a tail-call
Will>semantics for CALL-WITH-DYNAMIC-BINDING.
Unless, as usual, one is willing to test at such tail-calls
whether they redefine a dynamic variable, and if they do,
one does -not- save the corresponding binding since it would
be restored uselessly.
Price: more tests at runtime.
Evaluation: (1) calling and dynamically binding infinitely many
variables is not properly tail-recursive since only tail-recursive
calls that re-bind a variable can be performed properly;
(2) calling with N (N is finite) different dynamic variables
is properly tail-recursive "modulo" N.
So a "tail-call semantics" for CALL-WITH-DYNAMIC-BINDING is possible.
Most French Lisp systems actually used this technique.
Olivier
∂13-Aug-89 0537 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: Dynamic variables
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 13 Aug 89 05:37:35 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01697; Sun, 13 Aug 89 08:30:44 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22411;
11 Aug 89 16:42 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Aug 89 16:42:47 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa22366;
11 Aug 89 16:39 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA20395; Fri, 11 Aug 89 16:39:16 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 11 Aug 89 16:35:51 edt
Received: from Cabernet.ms by ArpaGateway.ms ; 11 AUG 89 13:35:43 PDT
Date: Fri, 11 Aug 89 13:37:00 PDT
From: Pavel.pa@xerox.com
Subject: Re: Dynamic variables
In-Reply-To: <8908111953.AA08745@spencer.cs.uoregon.edu>
To: will@cs.uoregon.edu
Cc: RRRS-Authors@zurich.ai.mit.edu
Message-Id: <890811-133543-9589@Xerox>
I'm afraid that I either don't see your ``right'' relationship or don't see
how to do the implementation. Could you be more explicit?
Also, if the deep binding is implemented more primitively, then you can
achieve tail-call semantics for CALL-WITH-DYNAMIC-BINDING; you simply
maintain the dynamic environment as an argument passed to every procedure.
CALL-WITH-DYNAMIC-BINDING then has an obvious implementation that
tail-calls the given thunk. I can't tell if this is in contradiction to
your final paragraph; perhaps you mean that the portable deep-binding
implementation you have in mind does not support tail-call semantics.
Pavel
∂13-Aug-89 2354 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: Dynamic variables
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 13 Aug 89 23:54:15 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00213; Mon, 14 Aug 89 02:44:21 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22730;
11 Aug 89 16:58 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Aug 89 16:59:07 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa22562;
11 Aug 89 16:47 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA20561; Fri, 11 Aug 89 16:47:26 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 11 Aug 89 16:44:00 edt
Received: from Cabernet.ms by ArpaGateway.ms ; 11 AUG 89 13:46:55 PDT
Date: Fri, 11 Aug 89 13:48:13 PDT
From: Pavel.pa@xerox.com
Subject: Re: Dynamic variables
In-Reply-To: <8908101539.AA11137@tekchips.LABS.TEK.COM>
To: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Cc: RRRS-Authors@zurich.ai.mit.edu
Message-Id: <890811-134655-9610@Xerox>
I find it bothersome that something called a "variable" can be the
result of an evaluation.
In some terminologies, the procedure CONS returns a pair of two variables;
that is, the word ``variable'' is synonymous with ``location''. I don't
particularly subscribe to that point of view, however.
Perhaps ``dynamic variable'' is a misnomer. Consider the environment and
store:
env: (1) --> (2)
store (2) --> (3)
I think that it's reasonably well-established that (2) is the set of
``locations'' and (3) is the set of ``values''. In lexical environments,
(1) is usually referred to as the set of ``identifiers''. One possibility
therefore is to change the specification to say that MAKE-DYNAMIC returns a
``dynamic identifier''. This doesn't quite sound right to me, though. How
about ``dynamic names''? I guess I don't really care what these frobs are
called.
My main concerns are that shared-memory multiprocessors are not
discriminated against and that the semantics of the rest of the language
not change dramatically with the addition of dynamic binding. The BASH
proposal grew out of my only idea satisfying these two concerns.
Pavel
∂14-Aug-89 0829 @mc.lcs.mit.edu,@life.ai.mit.edu:halstead@crl.dec.com Re: Arg evaluation order
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Aug 89 08:28:56 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA03007; Mon, 14 Aug 89 11:17:31 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25164;
11 Aug 89 20:03 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Aug 89 20:04:35 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa25050;
11 Aug 89 19:58 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA24767; Fri, 11 Aug 89 19:42:05 EDT
Received: from decwrl.dec.com (decwrl.dec.com) by zurich.ai.mit.edu; Fri, 11 Aug 89 19:38:43 edt
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
id AA03741; Fri, 11 Aug 89 16:41:23 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
for rrrs-authors@zurich.ai.mit.edu; id AA03741; Fri, 11 Aug 89 16:41:23 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
id AA21422; Fri, 11 Aug 89 18:34:11 EDT
Message-Id: <8908112233.AA08043@urmel.DEC.COM>
To: andy@ads.com
Cc: rrrs-authors@zurich.ai.mit.edu, rhh@hx.lcs.mit.edu
Subject: Re: Arg evaluation order
In-Reply-To: Your message of Thu, 13 Jul 89 22:28:54 -0400.
<8907140228.AA05095@crl.crl.dec.com>
Date: Fri, 11 Aug 89 18:33:30 EDT
From: halstead@crl.dec.com
This is a response to a rather old message -- but then again, a file
system lossage recently reset my state to July 17, causing me to take
a fresh look at some then-pending mail messages (and then the first
time I tried to send this message it bounced):
> Jinx writes:
> The problem is that there are perfectly portable sequential programs
> which work when ANY sequential order is used, but not when
> interleaved. Consider, for example, ...
> Now, a compiler should be able trivially to determine that node-mark!
> is a (potential) mutator, and hence that count-nodes! is a mutator;
> thus determining that there is a race condition just in case
> (eq? (node-left graph-node) (node-right graph-node))
> is straightforward, ....
Your argument here seems to be devoted to whether a compiler can tell
that, in this case, a parallel execution could yield a result different
from that of any legal sequential execution.
I don't think anybody is trying to *prevent* a Scheme implementation
from working in parallel, if it can prove that the result of such
operation will be equivalent to that of a legal sequential execution.
The issue here is whether the Scheme specification should be weakened
so as to include as a legal execution order the kind of interleaving
that Jinx's example highlights. I agree completely with Jinx that this
would be a radical change and would cause great difficulty in writing
portable programs. You can invent a language that is like Scheme in
every respect except that it relaxes this restriction (I have, in fact),
but that's different enough that you shouldn't call it Scheme.
-Bert Halstead
∂14-Aug-89 1634 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu Re: Dynamic variables
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Aug 89 16:34:26 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA08658; Mon, 14 Aug 89 19:22:18 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28953;
14 Aug 89 19:19 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Aug 89 19:19:07 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa28929;
14 Aug 89 19:15 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08586; Mon, 14 Aug 89 19:15:08 EDT
Received: from oregon.uoregon.edu (oregon.uoregon.edu) by zurich.ai.mit.edu; Mon, 14 Aug 89 19:11:40 edt
Received: from spencer.cs.uoregon.edu by oregon.uoregon.edu; Mon, 14 Aug 89
16:13 PDT
Received: by spencer.cs.uoregon.edu; Mon, 14 Aug 89 16:14:27 PDT
Date: Mon, 14 Aug 89 16:14:27 PDT
From: will@cs.uoregon.edu
Subject: Re: Dynamic variables
To: Pavel.pa@xerox.com
Cc: RRRS-Authors@zurich.ai.mit.edu
Message-Id: <8908142314.AA27913@spencer.cs.uoregon.edu>
I'm afraid that I either don't see your ``right'' relationship or don't see
how to do the implementation. Could you be more explicit?
No. I goofed. Sorry about that.
Peace, Will
∂15-Aug-89 1812 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #177
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Aug 89 18:12:26 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA10069; Tue, 15 Aug 89 20:28:39 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26313;
10 Aug 89 1:02 EDT
Date: 10 AUG 89 00:06:51 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Subject: Scheme Digest #177
To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id: <8908100102.aa26313@mintaka.lcs.mit.edu>
Scheme Digest #177 10 AUG 89 00:06:51 EDT
Today's Topics:
"Scheme has data types and Lisp doesn't."
functional command shells?
----------------------------------------------------------------------
Date: 9 Aug 89 16:00:44 GMT
From: Dan Weinreb <odi!valens!dlw@uunet.uu.net>
Subject: Re: "Scheme has data types and Lisp doesn't."
Message-Id: <410@odi.ODI.COM>
In article <13046@well.UUCP> nagle@well.UUCP (John Nagle) writes:
This is very confused. It's hard to know where to begin.
It's more of an MIT vs the rest of the LISP world tradition.
If you are contrasting Lisp and Scheme, it's hard to see how this can
be a conflict between MIT and the rest of the Lisp world. Scheme is
from MIT. Traditionally, the Lisps with the best numeric support,
compared to other Lisps, are *also* from MIT (particularly the NCOMPLR
for Maclisp).
Although Common LISP has data type declarations of a sort, they tend
not to be taken all that seriously by compilers.
This is not the case. Many major Lisp compilers for standard
hardware, such as Lucid and Franz, pay close attention to numeric
declarations, and produce far better numeric code when the
declarations are present.
CLTL is very weak
on this subject:
Yes; this is intentional. The idea is to accomodate both standard
hardware, for which the declarations are needed, and Lisp machines,
for which they are superfluous.
There's a faction in the LISP world that feels that
floating point is unimportant. The strongest expression of this feeling
was in the early Symbolics machines, which lacked floating point hardware.
What? The reason that the Symbolics LM-2 lacked floating point
hardware had nothing to do with a "strong expression of a feeling"; it
was due to marketing timing and economics. The LM-2 was just a
repackaged MIT prototype, and the idea was to get it shipped as fast
as possible, reserving improvements for later hardware platforms.
Machines that were actually designed by Symbolics all had floating
point accelerators, generally based on Weitek floating point chips.
Symbolics typically did very well in Lisp floating point benchmarks.
Furthermore, I know of no "faction" anywhere in the Lisp world that
claims that floating point is unimportant.
Much of the weakness on typing in Common Lisp reflects lobbying from the
Symbolics faction, which generally supported the idea that everything
possible should be dynamic.
That the language should not REQUIRE declarations. And it didn't
require any lobbying; the conventional-hardware faction agreed with
the philosophy that declarations should be optional hints from the
user to the compiler. Guy Steele, Richard Gabriel, and Scott Fahlman
never have advocated mandatory declarations of the types of variables
in Lisp. There was plenty of lobbying during the design of Common Lisp,
but not about this point.
Reading section 4.5 of CLTL (Common Lisp, the Language) will give
you a good feeling of the weakness of the commitment to strong typing
in Common Lisp.
You bet. There is no committment to "strong typing" (typed variables)
in Common Lisp. This is very much intentional.
What people tend to actually implement are systems in which all objects
are "LISP objects", and are still individually allocated and pointed to.
Yes, in the general case.
Defining an array of "short-float" is likely to generate an array of pointers
to LISP objects.
Nope. Not on Symbolics machines and not on the conventional-machine
implementations that I'm aware of. Lisp objects are not always
implemented as pointers; they can be stored "immediately". The
technique of doing this for numbers is nicknamed "inums" and has been
around for at least 15 years.
And none of this has anything to do with the original query, since
Lisp and Scheme are essentially the same in these regards. Scheme
doesn't have typed variables, either.
------------------------------
Date: 10 Aug 89 00:05:06 GMT
From: "Peter R. Ham" <shelby!polya!Polya.Stanford.EDU!ham@decwrl.dec.com>
Subject: functional command shells?
Message-Id: <HAM.89Aug9170506@Polya.Stanford.EDU>
Are any of these shells, like fsh, available?
--
Peter Ham PO Box 3430 (h)(415) 324-9645
MS Computer Science Student Stanford, CA ham@polya.stanford.edu
Stanford University 94309 (o)(415) 723-2067
------------------------------
End of Scheme Digest
********************
∂20-Aug-89 1056 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Programmer-defined data types
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Aug 89 10:55:58 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA03709; Sun, 20 Aug 89 13:37:59 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05421;
18 Aug 89 21:38 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Aug 89 21:38:47 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa05374;
18 Aug 89 21:35 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA10884; Fri, 18 Aug 89 21:34:46 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 18 Aug 89 21:31:16 edt
Received: from Cabernet.ms by ArpaGateway.ms ; 18 AUG 89 18:34:07 PDT
Date: Fri, 18 Aug 89 18:36:26 PDT
From: Pavel.pa@xerox.com
Subject: Programmer-defined data types
To: RRRS-Authors@zurich.ai.mit.edu
Cc: Pavel.pa@xerox.com
Message-Id: <890818-183407-4872@Xerox>
This is the proposal for adding records (aka programmer-defined data types,
aka opaque types) to Scheme, as approved by consensus at the first meeting
of BASH. It is derived from discussion at that meeting and messages to
RRRS-Authors on 8 Jul 87 and 26 May through 7 Jun 88.
I apologize in advance for the verbosity of the description; no good
precision-preserving abbreviations occurred to me as I was writing it up.
We propose adding the following procedures to Scheme:
(MAKE-RECORD-TYPE type-name slot-names)
Returns a ``record-type descriptor'', a value representing a new data type,
disjoint from all others. The type-name argument must be a string, but is
only used for debugging purposes (such as the printed representation of a
record of the new type). The slot-names argument is a list of symbols
naming the ``slots'' of a record of the new type. It is an error if the
list contains any duplicates.
(RECORD-CONSTRUCTOR rtd)
Returns a procedure for constructing new members of the type represented by
rtd. The returned procedure accepts exactly as many arguments as there
were slot-names in the call to MAKE-RECORD-TYPE that created the type
represented by rtd; these are used, in order, as the initial values of
those slots in a new record, which is returned by the constructor
procedure.
(RECORD-PREDICATE rtd)
Returns a procedure for testing membership in the type represented by rtd.
The returned procedure accepts exactly one argument and returns a true
value if the argument is a member of the indicated record type; it returns
a false value otherwise.
(RECORD-ACCESSOR rtd slot-name)
Returns a procedure for reading the value of a particular slot of a member
of the type represented by rtd. The returned procedure accepts exactly one
argument which must be a record of the appropriate type; it returns the
current value of the slot named by the symbol slot-name in that record.
The symbol slot-name must be a member of the list of slot-names in the call
to MAKE-RECORD-TYPE that created the type represented by rtd.
(RECORD-UPDATER rtd slot-name)
Returns a procedure for writing the value of a particular slot of a member
of the type represented by rtd. The returned procedure accepts exactly two
arguments: a record of the appropriate type and an arbitrary Scheme value;
it modifies the slot named by the symbol slot-name in that record to
contain the given value. The returned value of the updater procedure is
unspecified. The symbol slot-name must be a member of the list of
slot-names in the call to MAKE-RECORD-TYPE that created the type
represented by rtd.
(RECORD? obj)
Returns a true value if obj is a record of any type and a false value
otherwise.
(RECORD-TYPE-DESCRIPTOR record)
Returns a record-type descriptor representing the type of the given record.
That is, for example, if the returned descriptor were passed to
RECORD-PREDICATE, the resulting predicate would return a true value when
passed the given record. Note that it is not necessarily the case that the
returned descriptor is the one that was passed to RECORD-CONSTRUCTOR in the
call that created the constructor procedure that created the given record.
(RECORD-TYPE-NAME rtd)
Returns the type-name associated with the type represented by rtd. The
returned value is EQV? to the type-name argument given in the call to
MAKE-RECORD-TYPE that created the type represented by rtd.
(RECORD-TYPE-SLOT-NAMES rtd)
Returns a list of the symbols naming the slots in members of the type
represented by rtd. The returned value is EQUAL? to the slot-names
argument given in the call to MAKE-RECORD-TYPE that created the type
represented by rtd.
=====================
Notes on the proposal
=====================
[Some of the notes below are taken from the discussion in 1988.]
-- The only significant difference between this proposal and the one made
by Jonathan Rees in his message of 26 May 88 is the inclusion of procedures
to ``inspect'' records. These procedures were referred to as
``abstraction-breaking'' in Jonathan's proposal.
-- The procedure RECORD? is necessary to allow reliable use of the
procedure RECORD-TYPE-DESCRIPTOR.
-- The type-name argument to MAKE-RECORD-TYPE is constrained to be a string
in order to allow experimentation with interesting semantics for other
kinds of values there. One possibility raised in the discussion in 1988
was some kind of a ``handler'' procedure, as in T objects.
-- We do not propose any general macro for the definition of record types.
The feeling is that this is not easy to do in a way that is both elegant
and sufficiently flexible. Once we have macros, the primitives above
should be sufficient for portable experimentation.
-- Should there be a RECORD-COPIER procedure? Some folks would like to
have one for performance and convenience; others point out that a copier
for any particular type is easy to write. In fact, given the inspection
primitives above, one can even write a somewhat slow but general record
copying procedure that works on all types.
-- The issues of subtyping and inheritance, print methods, and integration
with modules and/or
environments (e.g. Pascal's WITH construct) have been purposely avoided in
order to achieve more rapid consensus. Designs for adding single
inheritance appeared in the discussion in 1988.
-- A case can be made that constructor procedures should take no arguments
and leave all slots in new records uninitialized. There appear to be
advantages to both points of view.
-- It is probably easy to agree on how EQ? and EQV? treat records; they
should be treated in the same way as pairs, vectors, and strings. The
consensus of those I've spoken to concerning EQUAL? is that it should be
equivalent to EQV? on records, instead of treating them as it treats
vectors, pairs, and strings. I have no opinion on the subject and look
forward to hearing any alternative points of view.
Pavel
∂21-Aug-89 1359 ramsdell@linus.mitre.org Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Aug 89 13:59:11 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA04683; Mon, 21 Aug 89 16:40:08 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA07583; Mon, 21 Aug 89 08:15:41 EDT
Posted-Date: Mon, 21 Aug 89 08:15:36 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA07557; Mon, 21 Aug 89 08:15:38 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908211215.AA07557@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Multiple values for R4RS.
Date: Mon, 21 Aug 89 08:15:36 EDT
Maybe there is enough consensus to allow agreement on the
non-controversial aspects of multiple values for R4RS. What do people
think about adding only VALUES and APPLY-VALUES?
-----------------Adapted from Mike Shaff <shaff@sesame.stanford.edu>.
(values obj ...) essential procedure
Returns 0 or more values to a receiving procedure (See apply-values).
(values) => returns zero (no) values
(values 1) => returns a single value, 1
(values 1 'a) => returns two values, 1 and the symbol a
(apply-values receiver generator) essential procedure
Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with no arguments. It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator' or if 'generator' cannot be called with zero arguments.
(apply-values cons
(lambda ()
(values 1 2))) => (1 . 2)
--------------------------------
Note: I think a useful extension of apply-values is
(apply-values receiver generator . generator-args)
Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with 'generator-args'. It
is an error if 'receiver' cannot be applied to the number of values
returned by 'generator' or if 'generator' cannot be called with the
number of values in 'generator-args'.
John
∂21-Aug-89 1450 cph@zurich.ai.mit.edu Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Aug 89 14:50:32 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA05287; Mon, 21 Aug 89 17:37:04 EDT
Received: from localhost by zurich.ai.mit.edu; Mon, 21 Aug 89 17:33:49 edt
Date: Mon, 21 Aug 89 17:33:49 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8908212133.AA24382@zurich.ai.mit.edu>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: ramsdell@linus.mitre.org's message of Mon, 21 Aug 89 08:15:36 EDT <8908211215.AA07557@huxley.mitre.org>
Subject: Multiple values for R4RS.
From: ramsdell@linus.mitre.org
Date: Mon, 21 Aug 89 08:15:36 EDT
Maybe there is enough consensus to allow agreement on the
non-controversial aspects of multiple values for R4RS. What do people
think about adding only VALUES and APPLY-VALUES?
I'm not sure how this circumvents the "controversial" aspects. As I
understood it, the controversy had to do with the semantics of how
VALUES interacted with the continuation in effect where it was called.
[...]
(apply-values receiver generator)
I've been using a similar interface for multiple values for about a
year now, the major difference being that instead of `apply-values'
there is an operation `with-values' which has these two arguments in
the opposite order. I think the order of arguments is somewhat
important: `with-values' orders the generator and receiver so that
they are executed in the same order in which they appear
(left-to-right), while `apply-values' executes them in the opposite
order. I think `with-values' is significantly easier to read; I'd
favor having the arguments appear in that order, even though it screws
up the "generator arguments" extension (sorry, I don't find that
extension very interesting). This is (at least part of) the same
reasoning that makes `let' easier to read than its `lambda' expansion.
∂21-Aug-89 1539 harris%hplwhh@hplabs.hp.com Re: Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Aug 89 15:39:28 PDT
Received: from hplms2.hpl.hp.com by life.ai.mit.edu (4.1/AI-4.10) id AA05826; Mon, 21 Aug 89 18:24:52 EDT
Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Mon, 21 Aug 89 14:26:10 pdt
Received: from localhost by hplwhh.HPL.HP.COM; Mon, 21 Aug 89 15:23:37 pdt
Message-Id: <8908212223.AA14032@hplwhh.HPL.HP.COM>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
Subject: Re: Multiple values for R4RS.
In-Reply-To: Your message of "Mon, 21 Aug 89 08:15:36 EDT."
<8908211215.AA07557@huxley.mitre.org>
Date: Mon, 21 Aug 89 15:23:33 PDT
From: Warren Harris <harris%hplwhh@hplabs.hp.com>
Your proposal doesn't say what happens when the number of values
expected by the receiver is different from the number the generator
produces. A simple case is when multiple values are returned and one
is expected:
(cons (values 1 2) 3)
=> (1 . 3)
=> (<?> . 3)
=> <error>
In the case of most functions (like CONS), I favor signaling an error,
but I can imagine some cases where passing multiple values as a single
parameter into a function should be permitted.
My argument stems from my discontent with Common Lisp when I have to
write code like:
(let ((a (foo)))
(multiple-value-bind (b c d)
(bar)
(let ((e (baz)))
...)))
when I would much prefer to write:
(let* ((a (foo))
((b c d) (bar))
(e (baz)))
...)
Granted, this can be accomplished by extending the syntax of LET*,
which in Scheme would expand to:
(let ((a (foo)))
(apply-values
(lambda (b c d)
(let ((e (baz)))
...))
(bar)))
but the same is not true of LET:
(let ((a (foo))
((b c d) (bar))
(e (baz)))
...)
-->
((lambda (a (b c d) e)
...)
(foo)
(bar)
(baz))
This suggests an extension of LAMBDA in which it may be specified that
multiple values can be passed in by a single parameter. In addition
to the conciseness this permits with LET and LET*, one could also
imagine writing code with this extended LAMBDA such as:
(define foo
(lambda (a (b c))
(list a b c)))
(foo 1 (values 2 3))
=> (1 2 3)
(foo 1 2)
=> <error>
---PROPOSAL---------------------------------------------------------------------
(LAMBDA <formals> <body>) essential syntax
<formals> ::= <variable>
| (<var/values>*)
| (<var/values>+ . <variable>)
<var/values> ::= <variable> ; single value
| (<var/values>*) ; multiple values
(LET (<binding spec>*) <body>) essential syntax
(LET* (<binding spec>*) <body>) essential syntax
<binding spec> ::= (<var/values> <expression>)
(VALUES . <expression>*) essential procedure
(APPLY-VALUES <receiver> <generator>) essential procedure
- with appropriate error messages when numbers of values mismatch.
- also suggest renaming APPLY to APPLY-LIST.
--------------------------------------------------------------------------------
Note that:
(apply-values (lambda (a b c) ...) (foo))
is equivalent to:
((lambda ((a b c)) ...) (foo))
I realize that the cost to implementors is much higher for this
proposal, but I think the power and conciseness of expression
justifies it.
Warren Harris
∂21-Aug-89 1543 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Aug 89 15:43:31 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA05856; Mon, 21 Aug 89 18:28:47 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09616;
21 Aug 89 11:39 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Aug 89 11:39:08 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa09594;
21 Aug 89 11:36 EDT
Received: from fafnir.think.com by Think.COM; Mon, 21 Aug 89 11:37:17 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 21 Aug 89 11:34:48 EDT
Received: by verdi.think.com; Mon, 21 Aug 89 11:34:37 EDT
Date: Mon, 21 Aug 89 11:34:37 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8908211534.AA29201@verdi.think.com>
To: Alan@reagan.ai.mit.edu
Cc: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden's message of Thu, 27 Jul 89 21:15 EDT <19890728011525.2.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Numbers
I'm back from an exhausting, and therefore very restful, vacation.
Back into the fray!
Date: Thu, 27 Jul 89 21:15 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
I wonder, by the way, what those of you who insist that MAX must return
something EQV? to one of its arguments because "MAX computes -the- maximum
of a set of numbers", think should be the answer in the case of (MAX 1 1.0)?
Either 1 or 1.0. By the same token I believe the result of (MAX 1 1)
may be either occurrence of "1" (by stating it this way I avoid
commmitment on the question of whether the two occurrences of "1" are
the same or not).
Here is a new proposal. Given a set of points within a partial order,
there are two interesting kinds of "max"-like operation. One is to find
some point (not necessarily within the set) that is >= all points in the
given set; this is SUP. In a general poset there may be many such points;
the lattice property guarantees uniqueness.
Another is to find some point in the set such that no point in the set is >
that point. This can fail for infinite sets, but that cannot occur in
Scheme. It may also be that there is more than one such point in the set.
In that case we must define some tie-breaking rule (arbitrary choice is one
such rule). One partial tie-breaking rule that I find appealing is to
choose one of the least exact of otherwise qualified candidates. I had
earlier proposed to call this second operation MAX.
The new proposal is the call the first kind SUP (as before), and to
call the second kind LARGEST (similarly INF and SMALLEST). Let Scheme
have no built-in operations called MIN and MAX.
I still believe both kinds of operation are useful. They reflect two
different points of view about inexact numbers. One is that they are
shadows of Platonically ideal real numbers, pitifully striving to mirror
the behavior of their exact counterparts and to retain some record of the
degree of their failure. The other is that they are objects unto
themselves, obeying perfectly an algebraic system that is useful because it
is similar, though not identical, to that for real numbers and much easier
to implement.
Theologically or politically speaking, under the first view inexact numbers
strive to obey laws acknowledged to be perfect, but to a greater or lesser
degree are each in a state of sin. Under the second view they are all
model citizens, adhering perfectly to their own laws which, however, are
acknowledged not to be ideal but merely the best one can do in this
imperfect and finite world.
--Guy
∂21-Aug-89 1652 jinx@hpesogg.hp.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Aug 89 16:52:26 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA06523; Mon, 21 Aug 89 19:38:03 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA24643; Mon, 21 Aug 89 16:37:52 pdt
Message-Id: <8908212337.AA24643@sde.hp.com>
Received: by hpesogg; Mon, 21 Aug 89 16:37:12 pdt
Date: Mon, 21 Aug 89 16:37:12 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Mon, 21 Aug 89 08:15:36 EDT <8908211215.AA07557@huxley.mitre.org>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com
Maybe there is enough consensus to allow agreement on the
non-controversial aspects of multiple values for R4RS. What do people
think about adding only VALUES and APPLY-VALUES?
I don't think they are worth adding if ACCEPTS? is not included as
well. ACCEPTS? allows a programmer to extend old operations into new
ones which match their continuation. For example, QUOTIENT can be
cleanly upgraded to return two values when expected, but its old
single value when only one is expected.
The reason Mike and Morry added ACCEPTS? to the proposal is that I
did not consider it interesting without some way of providing the
functionality that I want.
Without ACCEPTS?, their use and functionality can be provided in user
code, although without the error checking or the efficiency of a
"native" implementation.
∂22-Aug-89 0445 ramsdell@linus.mitre.org Re: Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 04:44:57 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02147; Tue, 22 Aug 89 07:21:23 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA28804; Tue, 22 Aug 89 07:16:10 EDT
Posted-Date: Tue, 22 Aug 89 07:16:05 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA08527; Tue, 22 Aug 89 07:16:07 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908221116.AA08527@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Re: Multiple values for R4RS.
In-Reply-To: Your message of Mon, 21 Aug 89 17:33:49 -0400.
<8908212133.AA24382@zurich.ai.mit.edu>
Date: Tue, 22 Aug 89 07:16:05 EDT
>> I'm not sure how this circumvents the "controversial" aspects. As I
>> understood it, the controversy had to do with the semantics of how
>> VALUES interacted with the continuation in effect where it was called.
Given Shaff's proposal, I thought the controversy was just over
ACCEPTS?. I thought the "obvious" semantics implied by the
denotational semantics had finally been accepted. Maybe I am wrong.
>>
>> [...]
>>
>> (apply-values receiver generator)
>>
>> I've been using a similar interface for multiple values for about a
>> year now, the major difference being that instead of `apply-values'
>> there is an operation `with-values' which has these two arguments in
>> the opposite order.
I too prefer the arguments in reverse order so that the most straight
forward extension of apply-values is to make a CPS style call.
(apply-value generator receiver . generator-args)
or using other names
(apply-values procedure continuation . procedure-args)
[continuation here means a procedure representing a continuation].
I thought the order of arguments is not important enought to stand in
the way of agreement. Maybe I am wrong.
>> From: Warren Harris <harris%hplwhh@hplabs.hp.com>
>>
>> Your proposal doesn't say what happens when the number of values
>> expected by the receiver is different from the number the generator
>> produces.
Sure it does. It clearly states "it is an error if 'receiver' cannot
be applied to the number of values returned by 'generator' or if
'generator' cannot be called with zero arguments". Warren, please
reread my proposal.
>> From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
>>
>> I don't think they are worth adding if ACCEPTS? is not included as
>> well.
....
>> Without ACCEPTS?, their use and functionality can be provided in user
>> code, although without the error checking or the efficiency of a
>> "native" implementation.
The point is that by adding just VALUES and APPLY-VALUES, programmers
can depend on the efficiency and error checking of a "native"
implementation.
John
---- Amended multiple values proposal.
(values obj ...) essential procedure
Returns 0 or more values to a receiving procedure (See apply-values).
(values) => returns zero (no) values
(values 1) => returns a single value, 1
(values 1 'a) => returns two values, 1 and the symbol a
(apply-values generator receiver) essential procedure
Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with no arguments. It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator' or if 'generator' cannot be called with zero arguments.
(apply-values
(lambda ()
(values 1 2))
cons) => (1 . 2)
--------------------------------
∂22-Aug-89 1052 harris%hplwhh@hplabs.hp.com Re: Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 10:52:34 PDT
Received: from hplms2.hpl.hp.com by life.ai.mit.edu (4.1/AI-4.10) id AA01885; Tue, 22 Aug 89 13:35:01 EDT
Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Tue, 22 Aug 89 09:38:41 pdt
Received: from localhost by hplwhh.HPL.HP.COM; Tue, 22 Aug 89 09:38:26 pdt
Message-Id: <8908221638.AA14520@hplwhh.HPL.HP.COM>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
Subject: Re: Multiple values for R4RS.
In-Reply-To: Your message of "Tue, 22 Aug 89 07:16:05 EDT."
<8908221116.AA08527@huxley.mitre.org>
Date: Tue, 22 Aug 89 09:38:22 PDT
From: Warren Harris <harris%hplwhh@hplabs.hp.com>
My apologies. Your proposal certainly does talk about number of
values mismatching. I guess I got excited about this extended lambda
idea.
∂22-Aug-89 1130 ramsdell@linus.mitre.org Re: Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 11:30:05 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02350; Tue, 22 Aug 89 14:05:24 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA02873; Tue, 22 Aug 89 14:00:12 EDT
Posted-Date: Tue, 22 Aug 89 14:00:07 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA08733; Tue, 22 Aug 89 14:00:09 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908221800.AA08733@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Re: Multiple values for R4RS.
In-Reply-To: Your message of Tue, 22 Aug 89 09:43:26 -0700.
<8908221643.AA01234@sesame.Stanford.EDU>
Date: Tue, 22 Aug 89 14:00:07 EDT
I cannot figure out what some of you would like me to conclude from
your responses. My premise is that VALUES and APPLY-VALUES as defined
reflect existing practice in some Scheme dialects, are useful, and are
non-controversial enough to add to R4RS. Let me suggest some
questions to answer which may help clear up my confusion.
[1] Do you think VALUES and APPLY-VALUES as defined are controversial?
(I understand CPH's view on this issue).
[2] Do you think VALUES and APPLY-VALUES as defined reflect existing
practice? For example, in T, VALUES = RETURN, and APPLY-VALUES =
(LAMBDA (X Y) (RECEIVE-VALUES Y X)), and MIT Scheme has the
functionality.
[3] Do you think VALUES and APPLY-VALUES as defined prohibit the
future inclusion of ACCEPTS? or some other proposal to deal with
incompatiable arities?
[4] Do you believe VALUES and APPLY-VALUES should be excluded from
Scheme solely because there is no agreement on how to deal with
incompatiable arities?
John
---- Amended multiple values proposal.
(values obj ...) essential procedure
Returns 0 or more values to a receiving procedure (See apply-values).
(values) => returns zero (no) values
(values 1) => returns a single value, 1
(values 1 'a) => returns two values, 1 and the symbol a
(apply-values generator receiver) essential procedure
Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with no arguments. It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator' or if 'generator' cannot be called with zero arguments.
(apply-values
(lambda ()
(values 1 2))
cons) => (1 . 2)
--------------------------------
∂22-Aug-89 1150 mkatz@sesame.stanford.edu Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 11:50:13 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA02587; Tue, 22 Aug 89 14:25:33 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA01234; Tue, 22 Aug 89 09:43:26 PDT
Date: Tue, 22 Aug 89 09:43:26 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8908221643.AA01234@sesame.Stanford.EDU>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Mon, 21 Aug 89 08:15:36 EDT <8908211215.AA07557@huxley.mitre.org>
Subject: Multiple values for R4RS.
∂22-Aug-89 1221 dyb@iuvax.cs.indiana.edu Re: Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 12:21:00 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02931; Tue, 22 Aug 89 14:51:14 EDT
Message-Id: <8908221851.AA02931@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Tue, 22 Aug 89 13:51:43 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: jinx%hpesogg@sde.hp.com
Subject: Re: Multiple values for R4RS.
Cc: rrrs-authors@life.ai.mit.edu
Let me take a stab at "quotient-and-maybe-remainder":
(define quotient-and-maybe-remainder
(lambda (n1 n2)
(call/cc
(lambda (k)
(if (accepts? k 2)
(let ([q (quotient n1 n2)])
(let ([r (- n1 (* q n2))])
(k q r)))
(k (quotient n1 n2)))))))
Unless I'm missing something and there is a different way to do this, I
guess I'm not too excited about "accepts?".
The predicate "accepts?" seems a little like the (rejected) predicate
"continuation?". A procedure may not complain "up front" about a given
number of arguments, but may complain at some later time. Or it may
accept any number of arguments, but ignore all but the first few. I
don't see how "accepts?" can be generally useful if it breaks down in
these cases.
(define kons
(lambda l
(apply cons l)))
(accepts? cons 3) => #f
(accepts? kons 3) => #t
Kent
∂22-Aug-89 1234 mkatz@sesame.stanford.edu Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 12:32:52 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA03066; Tue, 22 Aug 89 15:08:15 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA01234; Tue, 22 Aug 89 09:43:26 PDT
Date: Tue, 22 Aug 89 09:43:26 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8908221643.AA01234@sesame.Stanford.EDU>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Mon, 21 Aug 89 08:15:36 EDT <8908211215.AA07557@huxley.mitre.org>
Subject: Multiple values for R4RS.
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Posted-Date: Mon, 21 Aug 89 08:15:36 EDT
From: ramsdell@linus.mitre.org
Date: Mon, 21 Aug 89 08:15:36 EDT
Maybe there is enough consensus to allow agreement on the
non-controversial aspects of multiple values for R4RS. What do people
think about adding only VALUES and APPLY-VALUES?
In the past, Jinx has given a cogent argument as to why the procedure arity is
important for enabling implementors to experiment with upward compatible
versions of the core language. In essence, the idea is that one might want to
create an upward compatible version of a function which returns more values
than the one specified in RNRS. Since our proposal requires that the
return-arity of the generator be compatible with the arity of the receiver,
this can only be done if the generator can determine the arity of the receiver
and return an appropriate number of values. I personally find this argument
persuasive.
Note: I think a useful extension of apply-values is
(apply-values receiver generator . generator-args)
This might me a useful addition to the yellow pages; but, I would oppose making
this form op apply-values the required one.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂22-Aug-89 1339 mkatz@sesame.stanford.edu Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 13:39:32 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA03764; Tue, 22 Aug 89 15:59:21 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00379; Tue, 22 Aug 89 12:58:10 PDT
Date: Tue, 22 Aug 89 12:58:10 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8908221958.AA00379@sesame.Stanford.EDU>
To: cph@zurich.ai.mit.edu
Cc: ramsdell@linus.mitre.org, rrrs-authors@life.ai.mit.edu
In-Reply-To: Chris Hanson's message of Mon, 21 Aug 89 17:33:49 edt <8908212133.AA24382@zurich.ai.mit.edu>
Subject: Multiple values for R4RS.
Date: Mon, 21 Aug 89 17:33:49 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
From: ramsdell@linus.mitre.org
Date: Mon, 21 Aug 89 08:15:36 EDT
I've been using a similar interface for multiple values for about a
year now, the major difference being that instead of `apply-values'
there is an operation `with-values' which has these two arguments in
the opposite order.
I personally also favor the with-values order of generator and then receiver as
opposed to the apply-values order. Mike and I chose the apply-values order for
consistency with the regularization of procedures in Scheme. Since the
regularization of apply has been nixed, there remains no reason for the
apply-values order.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂22-Aug-89 1359 mkatz@sesame.stanford.edu Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 13:59:33 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA03898; Tue, 22 Aug 89 16:10:19 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00404; Tue, 22 Aug 89 13:09:03 PDT
Date: Tue, 22 Aug 89 13:09:03 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8908222009.AA00404@sesame.Stanford.EDU>
To: harris%hplwhh@hplabs.hp.com
Cc: ramsdell@linus.mitre.org, rrrs-authors@life.ai.mit.edu
In-Reply-To: Warren Harris's message of Mon, 21 Aug 89 15:23:33 PDT <8908212223.AA14032@hplwhh.HPL.HP.COM>
Subject: Multiple values for R4RS.
Date: Mon, 21 Aug 89 15:23:33 PDT
From: Warren Harris <harris%hplwhh@hplabs.hp.com>
Your proposal doesn't say what happens when the number of values
expected by the receiver is different from the number the generator
produces. A simple case is when multiple values are returned and one
is expected:
(cons (values 1 2) 3)
=> (1 . 3)
=> (<?> . 3)
=> <error>
I believe that we explicitly stated that the return-arity must be compatible
with the arity of the receiver. If we forget about rest arguments for a
moment, compatible was defined as identical. In the case above, the arity of
the implicit continuation to cons is 1 and the return-arity of values is 2, so
there is an arity incompatibility. We proposed that arity incompatibilities
are an error (not signal an error). This leaves open the ability for some
implementors to create extensions to multiple values which are not strict
without violating RNRS.
extensions that some
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂22-Aug-89 1415 jinx@hpesogg.hp.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 14:15:36 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA04404; Tue, 22 Aug 89 16:50:49 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA22154; Tue, 22 Aug 89 13:17:22 pdt
Message-Id: <8908222017.AA22154@sde.hp.com>
Received: by hpesogg; Tue, 22 Aug 89 13:16:43 pdt
Date: Tue, 22 Aug 89 13:16:43 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: R. Kent Dybvig's message of Tue, 22 Aug 89 13:51:43 -0500 <8908221851.AA02931@life.ai.mit.edu>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com
The predicate "accepts?" seems a little like the (rejected) predicate
"continuation?". A procedure may not complain "up front" about a given
number of arguments, but may complain at some later time. Or it may
accept any number of arguments, but ignore all but the first few. I
don't see how "accepts?" can be generally useful if it breaks down in
these cases.
This is like saying that a given object may pass a PAIR? test yet when
given to a list operation, the operation will flame. Just because it
does not cover all cases, it does not mean that it is useless. Are
you advocating for removing PAIR? from the language?
∂22-Aug-89 1432 jinx@hpesogg.hp.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 14:31:48 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA04470; Tue, 22 Aug 89 16:59:39 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA22411; Tue, 22 Aug 89 13:31:40 pdt
Message-Id: <8908222031.AA22411@sde.hp.com>
Received: by hpesogg; Tue, 22 Aug 89 13:31:00 pdt
Date: Tue, 22 Aug 89 13:31:00 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Tue, 22 Aug 89 14:00:07 EDT <8908221800.AA08733@huxley.mitre.org>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com
[2] Do you think VALUES and APPLY-VALUES as defined reflect existing
practice? For example, in T, VALUES = RETURN, and APPLY-VALUES =
(LAMBDA (X Y) (RECEIVE-VALUES Y X)), and MIT Scheme has the
functionality.
MIT Scheme does not quite have it. It is not integrated with
continuations at all (I don't know if T's is either). I think that it
is not worth putting in, if I cannot accomodate users who would like
Common Lisp style truncation of values, or who want to be able to port
Common Lisp code a little more easily. I find the backwards
compatibility that "truncation" offers to be the most significant
feature in multiple values, and would use CPS otherwise.
[3] Do you think VALUES and APPLY-VALUES as defined prohibit the
future inclusion of ACCEPTS? or some other proposal to deal with
incompatiable arities?
Certainly not TECHNICALLY, but it is my POLITICAL feeling, that if it
is not accepted as a complete package, it will not be accepted later.
The people who want the "restrictive" multiple values will feel no
pressure to accept it later since they will already have what they
want. I'm not asking for their semantics to be different (I've
compromised on paranoid checking by default), but I would like a
little compromise on everyone else's part.
I view ACCEPTS? as a harmless little addition, and don't understand
what the fuss is all about.
[4] Do you believe VALUES and APPLY-VALUES should be excluded from
Scheme solely because there is no agreement on how to deal with
incompatiable arities?
That is the reason why they have been excluded up to now. Perhaps a
compromise is not possible.
∂22-Aug-89 1445 @relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 14:45:03 PDT
Received: from MIT.EDU (MIT.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04654; Tue, 22 Aug 89 17:15:52 EDT
Received: from RELAY.CS.NET by MIT.EDU with SMTP
id AA03014; Tue, 22 Aug 89 17:15:40 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa08811; 22 Aug 89 17:12 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA20162; Tue, 22 Aug 89 14:15:05 PDT
Received: by tekirl.labs.tek.com (5.51/7.1)
id AA26560; Tue, 22 Aug 89 14:13:00 PDT
Received: by tekchips.LABS.TEK.COM (5.51/6.24)
id AA24785; Tue, 22 Aug 89 14:15:28 PDT
Date: Tue, 22 Aug 89 14:15:28 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Message-Id: <8908222115.AA24785@tekchips.LABS.TEK.COM>
To: jinx%hpesogg@sde.hp.com
Cc: ramsdell%linus.mitre.org@relay.cs.net,
rrrs-authors%life.ai.mit.edu@relay.cs.net
Subject: Multiple values for R4RS.
From: ramsdell@linus.mitre.org
Maybe there is enough consensus to allow agreement on the
non-controversial aspects of multiple values for R4RS. What do people
think about adding only VALUES and APPLY-VALUES?
I'd take this, or VALUES and WITH-VALUES.
From: jinx%hpesogg@sde.hp.COM
I don't think they are worth adding if ACCEPTS? is not included as
well. ...
This is an extreme position. The proposed functionality is
useful even in the absence of ACCEPTS?
From: Morris Katz <mkatz@sesame.stanford.edu>
In the past, Jinx has given a cogent argument as to why the
procedure arity is important ...
I remain unconvinced. As a user, I have found multiple values
(without ACCEPTS?) quite useful. So, I don't think ACCEPTS? provides
super-essential functionality. As an implementor, I would prefer not
to be committed to keeping around arity information for every
procedure.
-Norman
∂22-Aug-89 1448 jinx@hpesogg.hp.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 14:48:32 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AB04683; Tue, 22 Aug 89 17:22:20 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA23597; Tue, 22 Aug 89 14:20:31 pdt
Message-Id: <8908222120.AA23597@sde.hp.com>
Received: by hpesogg; Tue, 22 Aug 89 14:19:50 pdt
Date: Tue, 22 Aug 89 14:19:50 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: adams@tekchips.labs.tek.com
Cc: ramsdell@linus.mitre.org, rrrs-authors@life.ai.mit.edu
In-Reply-To: Norman Adams's message of Tue, 22 Aug 89 14:15:28 PDT <8908222115.AA24785@tekchips.LABS.TEK.COM>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com
This is an extreme position. The proposed functionality is
useful even in the absence of ACCEPTS?
It's much less extreme than imposing a particular fascist semantics on
those who don't find it interesting or useful. Usefulness is an
aesthetic measure, and I find CPS better if I'm going to be fascist.
I remain unconvinced. As a user, I have found multiple values
(without ACCEPTS?) quite useful. So, I don't think ACCEPTS? provides
super-essential functionality. As an implementor, I would prefer not
to be committed to keeping around arity information for every
procedure.
You don't have to keep it around for every procedure. Just those
procedurs that might be given to ACCEPTS? as arguments. This may seem
silly, but I'm not kidding. This effectively means that only closures
(and not all of them) need to have this information. The MIT Scheme
compiler keeps arity information only for procedures that it
determines may be invoked from places that "don't know about them."
This turns out to be but a fraction of the total in typical code.
∂22-Aug-89 1606 mkatz%sesame.stanford.edu@relay.cs.net Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 16:06:51 PDT
Received: from MIT.EDU (MIT.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA05225; Tue, 22 Aug 89 18:36:21 EDT
Received: from RELAY.CS.NET by MIT.EDU with SMTP
id AA03116; Tue, 22 Aug 89 18:36:11 EDT
Received: from sesame.stanford.edu by RELAY.CS.NET id aa12554;
22 Aug 89 18:36 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00236; Tue, 22 Aug 89 15:34:50 PDT
Date: Tue, 22 Aug 89 15:34:50 PDT
From: Morris Katz <mkatz%sesame.stanford.edu@relay.cs.net>
Message-Id: <8908222234.AA00236@sesame.Stanford.EDU>
To: adams%tekchips.labs.tek.com@relay.cs.net
Cc: jinx%hpesogg@sde.hp.com, ramsdell%linus.mitre.org@relay.cs.net,
rrrs-authors%life.ai.mit.edu@relay.cs.net
In-Reply-To: Norman Adams's message of Tue, 22 Aug 89 14:15:28 PDT <8908222115.AA24785@tekchips.LABS.TEK.COM>
Subject: Multiple values for R4RS.
Date: Tue, 22 Aug 89 14:15:28 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
As an implementor, I would prefer not
to be committed to keeping around arity information for every
procedure.
I can't imagine how one could create an implementation in which the arity
information is not already present in some form for procedures that are passed
as arguments. Similarly, implicit continuations had better know something
about the number of values on which they intend to operate. Retrieving the
arity information may require some bit twiddling, but I suspect that the needed
information is always present in some form.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂22-Aug-89 1634 cph@zurich.ai.mit.edu Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 16:34:29 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA05339; Tue, 22 Aug 89 19:06:45 EDT
Received: from localhost by zurich.ai.mit.edu; Tue, 22 Aug 89 19:03:31 edt
Date: Tue, 22 Aug 89 19:03:31 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8908222303.AA04769@zurich.ai.mit.edu>
To: jinx%hpesogg@sde.hp.com
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Tue, 22 Aug 89 14:19:50 pdt <8908222120.AA23597@sde.hp.com>
Subject: Multiple values for R4RS.
Date: Tue, 22 Aug 89 14:19:50 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
This is an extreme position. The proposed functionality is
useful even in the absence of ACCEPTS?
It's much less extreme than imposing a particular fascist semantics on
those who don't find it interesting or useful.
I agree, with Norman, that the proposed functionality is useful in the
absence of `accepts?'. However, tossing around words like "extreme"
and "fascist" in this fashion seems hypocritical. Aside from the
differing emotional charges attached to these phrases, both seem to
have the same purpose: discrediting the opposition by distancing them
from the hypothetical "middle ground" (or "moral majority" if you
prefer the three-red-stars-extra-spicy emotional charge). Let's try
not to make arguments that presume knowledge of the consensus.
As an aside, I have no objection to implementing `accepts?'; I think
that it is very useful, whether or not you have multiple values. But
I dislike that particular name because it is too vague; I'd prefer
something more like `procedure-accepts?' or (as in MIT Scheme)
`procedure-arity-valid?'.
[2] Do you think VALUES and APPLY-VALUES as defined reflect existing
practice? For example, in T, VALUES = RETURN, and APPLY-VALUES =
(LAMBDA (X Y) (RECEIVE-VALUES Y X)), and MIT Scheme has the
functionality.
MIT Scheme does not quite have it. It is not integrated with
continuations at all (I don't know if T's is either). I think that it
is not worth putting in, if I cannot accomodate users who would like
Common Lisp style truncation of values, or who want to be able to port
Common Lisp code a little more easily. I find the backwards
compatibility that "truncation" offers to be the most significant
feature in multiple values, and would use CPS otherwise.
I disagree with this statement -- multiple values have usefulness
independent of the "truncation" feature, and I feel they are worth
having anyway. Despite the fact that MIT Scheme's multiple values are
not fully implemented, I have found them quite useful and I have
written much code that uses them.
CL's handling of "extra" values is distasteful to me, because it makes
the standard behavior complicated; I think that values should be
discarded only when that is explicitly stated by the code. This is
not to say that I would be extremely upset should such a semantics be
adopted, because I would just avoid using "truncation". But on
aesthetic grounds I would prefer something simpler.
∂22-Aug-89 1713 jinx@hpesogg.hp.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 17:13:51 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA05583; Tue, 22 Aug 89 19:44:24 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA27806; Tue, 22 Aug 89 16:44:08 pdt
Message-Id: <8908222344.AA27806@sde.hp.com>
Received: by hpesogg; Tue, 22 Aug 89 16:43:26 pdt
Date: Tue, 22 Aug 89 16:43:26 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: cph@zurich.ai.mit.edu
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: Chris Hanson's message of Tue, 22 Aug 89 19:03:31 edt <8908222303.AA04769@zurich.ai.mit.edu>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com
CL's handling of "extra" values is distasteful to me, because it makes
the standard behavior complicated; I think that values should be
discarded only when that is explicitly stated by the code. This is
not to say that I would be extremely upset should such a semantics be
adopted, because I would just avoid using "truncation". But on
aesthetic grounds I would prefer something simpler.
I don't object to this position. I object to trying to force this
position down my throat.
∂22-Aug-89 1740 @relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 17:40:40 PDT
Received: from MIT.EDU (MIT.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA05739; Tue, 22 Aug 89 20:12:27 EDT
Received: from RELAY.CS.NET by MIT.EDU with SMTP
id AA03209; Tue, 22 Aug 89 20:12:16 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa16619; 22 Aug 89 20:11 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA26764; Tue, 22 Aug 89 17:13:40 PDT
Received: by tekirl.labs.tek.com (5.51/7.1)
id AA13649; Tue, 22 Aug 89 17:11:35 PDT
Received: by tekchips.LABS.TEK.COM (5.51/6.24)
id AA26483; Tue, 22 Aug 89 17:14:03 PDT
Date: Tue, 22 Aug 89 17:14:03 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Message-Id: <8908230014.AA26483@tekchips.LABS.TEK.COM>
To: jinx%hpesogg@sde.hp.com,
Morris Katz <mkatz%sesame.stanford.edu@relay.cs.net>
Cc: rrrs-authors%life.ai.mit.edu@relay.cs.net, adams@tekchips.labs
In-Reply-To: "Guillermo J. Rozas"'s message of Tue, 22 Aug 89 14:19:50 pdt <8908222120.AA23597@sde.hp.com>
Subject: Multiple values for R4RS.
From: adams@tekchips.LABS.TEK.COM
I would prefer not
to be committed to keeping around arity information for every
procedure.
From: jinx@hpesogg.hp.COM
You don't have to keep it around for every procedure.
I know. And this is a side issue. I want multiple values, and I don't
want to get hung up on ACCEPTS?.
If you are interested in the side issue, here are my thoughts:
The requirement that some procedures support ACCEPTS? still imposes
constraints on the implementation. You must have a representation of
procedures that can support ACCEPTS? As an implementor, this is the
sort of language-imposed restriction I have found useful to eliminate.
From: mkatz%sesame.stanford.edu
I can't imagine how one could create an implementation in which the arity
information is not already present in some form for procedures that
are passed
Sure, it is present in some form.
Perhaps each procedure is responsible for coping with wrong number of
arguments passed in. Somewhere in the procedure's code are
instructions that perform the check. The information is there, but
with a sufficiently clever compiler -- the sort of implementation I
find most interesting -- finding that information could be
impractical, if not intractable.
-Norman
∂22-Aug-89 1824 @spencer.cs.uoregon.edu:will@cs.uoregon.edu multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 18:24:10 PDT
Received: from skinner.cs.uoregon.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06118; Tue, 22 Aug 89 21:07:08 EDT
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA23975; Tue, 22 Aug 89 18:07:08 PDT
Received: by spencer.cs.uoregon.edu; Tue, 22 Aug 89 18:07:02 PDT
Date: Tue, 22 Aug 89 18:07:02 PDT
From: will@cs.uoregon.edu
Message-Id: <8908230107.AA29487@spencer.cs.uoregon.edu>
To: rrrs-authors@life.ai.mit.edu
Subject: multiple values
Morry Katz:
I can't imagine how one could create an implementation in which the arity
information is not already present in some form for procedures that are
passed as arguments. Similarly, implicit continuations...
Passing an incorrect number of arguments to a procedure isn't required to
signal an error, so procedures don't have to check it. Hence the arity may
not be retrievable through any amount of bit-twiddling. Also, why should
the run-time representation of (lambda args #t) include any bits that
indicate the number of arguments it expects? As a third example, the
variety and complexity of code sequences emitted by multiple compilers
may make the arity unrecoverable when embedded within code. Similarly
for continuations.
That said, I don't think ACCEPTS? would be an unreasonable burden on any
implementor. But it's certainly a burden that doesn't exist now.
Chris Hanson:
I agree, with Norman, that the proposed functionality is useful in the
absence of `accepts?'.
I agree with Chris and Norman.
Chris Hanson:
...multiple values have usefulness independent of the "truncation"
feature, and I feel they are worth having anyway.
I agree again. I believe the multiple values proposal being considered
allows the "truncation" feature as an extension: the critical property
is that (VALUES E) is always equivalent to E.
Peace, Will
∂22-Aug-89 1838 @spencer.cs.uoregon.edu:will@cs.uoregon.edu theology; MAX and MIN
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 18:37:57 PDT
Received: from skinner.cs.uoregon.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06133; Tue, 22 Aug 89 21:08:19 EDT
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA23985; Tue, 22 Aug 89 18:08:32 PDT
Received: by spencer.cs.uoregon.edu; Tue, 22 Aug 89 18:08:24 PDT
Date: Tue, 22 Aug 89 18:08:24 PDT
From: will@cs.uoregon.edu
Message-Id: <8908230108.AA29492@spencer.cs.uoregon.edu>
To: rrrs-authors@life.ai.mit.edu
Subject: theology; MAX and MIN
Note to Jim Miller: My mail to you has bounced. How did your poll on
this issue come out?
Guy Steele Jr:
Theologically or politically speaking, under the first view inexact numbers
strive to obey laws acknowledged to be perfect, but to a greater or lesser
degree are each in a state of sin. Under the second view they are all
model citizens, adhering perfectly to their own laws which, however, are
acknowledged not to be ideal but merely the best one can do in this
imperfect and finite world.
In the imperfect world I live in, the supremum implied by the phrase
"the best one can do" is even less likely to exist than in the world of
computer arithmetic.
Theologically speaking, Guy's new proposal has the same problem as his old
proposal: It introduces two new demons to undermine a user's faith in
exact numbers. Only the names have changed: now the demons are called
LARGEST and SMALLEST. The damage done by these two procedures won't be
ameliorated by having exactness-preserving SUP and INF as well. For
simplicity, I say that if MAX and MIN, by whatever names, are going to be
exceptions to the perfect rules of exactness, then let's just acknowledge
them as exceptions and to hell, theologically speaking, with the sinfully
striving exactness-preserving versions.
Guy Steele Jr:
But my point of view is that the MAX operation per se, like other C
operators is *not* polymorphic. They operate only on two ints or
two floats. The type mechanism enforces this requirement by inserting
coercions; the point is that these coercions are outside the control
of the implementation of the operation itself, and therefore not
properly a part of them. In exactly the same way that max(2.5, 1000)
in an int context ends up having a coercion inserted, so the coercion
that converts 1000 to a float is artificially inserted.
It doesn't matter how you look at it. My point is that, contrary
to some recent discussion in RRRS-AUTHORS, experience with mainstream
programming languages has conditioned programmers to expect expressions
like (MAX 2.5 1000) to evaluate to an inexact number. I pointed this
out to dispose of a bogus argument, not to argue that programmers'
expectations should decide the issue. Expectations formed by other
languages aren't necessarily met by arithmetic in Scheme, precisely
because arithmetic in Scheme is more generic (polymorphic, if you will)
than in other languages.
Peace, Will
∂22-Aug-89 1842 jinx@hpesogg.hp.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 18:42:06 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA05920; Tue, 22 Aug 89 20:44:41 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA29418; Tue, 22 Aug 89 17:43:51 pdt
Message-Id: <8908230043.AA29418@sde.hp.com>
Received: by hpesogg; Tue, 22 Aug 89 17:43:10 pdt
Date: Tue, 22 Aug 89 17:43:10 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: adams@tekchips.labs.tek.com
Cc: mkatz%sesame.stanford.edu@relay.cs.net, rrrs-authors@life.ai.mit.edu,
adams@tekchips.labs
In-Reply-To: Norman Adams's message of Tue, 22 Aug 89 17:14:03 PDT <8908230014.AA26483@tekchips.LABS.TEK.COM>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com
Perhaps each procedure is responsible for coping with wrong number of
arguments passed in. Somewhere in the procedure's code are
instructions that perform the check. The information is there, but
with a sufficiently clever compiler -- the sort of implementation I
find most interesting -- finding that information could be
impractical, if not intractable.
With a sufficiently clever compiler, the information should not be in
the code, since all checks have been done at compile time :-)
The MIT compiler used to output instructions to do arity checks at
runtime, but now the dynamic linker checks for arity mismatches when
definitions or assignments occur, thus rendering the runtime check a
waste of time in most of the cases. The only cases where arity needs
to be checked at runtime in (compiled) MIT Scheme are things like
((car some-pair) arg1 arg2 arg3)
where the shape of the car of SOME-PAIR is not known at compile time.
The arity information is present in fixed format in "external
procedures" so that the linker (a fixed program) can check for
mismatches and create the appropriate trampolines at run time. The
information is encoded so that the runtime check in cases like the
above is very fast when the number of arguments passed matches exactly
the number of arguments expected, and can be coded in-line, although
we don't do it right now.
The arity information only makes the output code be slightly larger in
a few cases, but hardly affects the time performance. Except for
garbage collection time (compiled code objects are slightly larger),
and closure creation time (the closures must contain the arity
information if they are passed to "unknown" places), the time penalty
is very small, and I suspect that on the average, it is smaller than
in your model.
In our implementation we multiplex this information with debugging
information (how many words are on the stack "on top" of a return
address, the kind of compiled entry point this is, etc), and it takes
16 bits per external entry point (whether a compiled procedure,
expression, return address or other), which we feel is not an excesive
space penalty.
Another possibility is to encode the arity information redundantly.
One encoding is for the actual runtime check, the other for ACCEPTS?
or similar procedures. Note that this redundant encoding need not
take any space in the runtime image, since the compiler can produce
another object when compiling code, associating PCs to arities, and
this can be kept on an external "file", loaded only when someone uses
ACCEPTS?
In general, I find that implementation efficiency arguments based on
details of particular implementation strategies don't carry much
weight because two days later someone finds a different implementation
strategy that jiggles the trade-offs, but maintains the semantics.
Note that I don't need ACCEPTS? to be particularly efficient, since it
will only be used to provide an expensive portability hook.
Implementations that are sincerely interested in supporting less
strict return arity checking will want to provide a more efficient
primitive mechanism.
∂22-Aug-89 2037 dyb@iuvax.cs.indiana.edu Re: Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 20:36:52 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07736; Tue, 22 Aug 89 23:14:59 EDT
Message-Id: <8908230314.AA07736@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Tue, 22 Aug 89 22:15:25 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: jinx%hpesogg@sde.hp.com
Subject: Re: Multiple values for R4RS.
Cc: rrrs-authors@life.ai.mit.edu
> The predicate "accepts?" seems a little like the (rejected) predicate
> "continuation?". A procedure may not complain "up front" about a given
> number of arguments, but may complain at some later time. Or it may
> accept any number of arguments, but ignore all but the first few. I
> don't see how "accepts?" can be generally useful if it breaks down in
> these cases.
>
> This is like saying that a given object may pass a PAIR? test yet when
> given to a list operation, the operation will flame. Just because it
> does not cover all cases, it does not mean that it is useless. Are
> you advocating for removing PAIR? from the language?
There is a difference that I'm surprised you don't see. When "pair?"
returns #t for an object, I know that I can use "car" or "cdr" without
causing an error. No similar claim can be made for "accepts?".
If we decide to add "accepts?" to the language, we would have to say
that an implementation is free to return #t if it cannot determine
whether or not a given number of arguments is accepted by a given
procedure. An implementation might even define "accepts?" as:
(lambda (procedure arity) #t)
This may seem to water down the predicate, but it only makes explicit
that which must already be true.
Kent
∂22-Aug-89 2052 dyb@iuvax.cs.indiana.edu Re: Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 20:52:11 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07971; Tue, 22 Aug 89 23:30:36 EDT
Message-Id: <8908230330.AA07971@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Tue, 22 Aug 89 22:31:06 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: jinx%hpesogg@sde.hp.com
Subject: Re: Multiple values for R4RS.
Cc: rrrs-authors@life.ai.mit.edu
> Certainly not TECHNICALLY, but it is my POLITICAL feeling, that if it
> is not accepted as a complete package, it will not be accepted later.
> The people who want the "restrictive" multiple values will feel no
> pressure to accept it later since they will already have what they
> want. I'm not asking for their semantics to be different (I've
> compromised on paranoid checking by default), but I would like a
> little compromise on everyone else's part.
As long as we are considering the issues politically rather than
technically, how would you feel about the following compromises?
* let's add "values" and "with-values" (or "apply-values") and
change the name of the so-called "named let" to "recur".
* let's add "accepts?" and remove the requirement that Scheme
be case insensitive.
These may be considered together or separately, as you desire.
Kent
∂22-Aug-89 2105 dyb@iuvax.cs.indiana.edu Re: multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 21:05:38 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08061; Tue, 22 Aug 89 23:45:04 EDT
Message-Id: <8908230345.AA08061@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Tue, 22 Aug 89 22:45:40 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: rrrs-authors@life.ai.mit.edu, will@cs.uoregon.edu
Subject: Re: multiple values
> I agree again. I believe the multiple values proposal being considered
> allows the "truncation" feature as an extension: the critical property
> is that (VALUES E) is always equivalent to E.
And this is the feature I'm most critical of. Unless an implementation
does support the truncation feature, I don't see any reason why we should
require that "(values e)" be equivalent to "e". I would like to feel
free to signal an error if "(values e)" is returned to a context that
is not prepared to accept multiple values.
Kent
∂23-Aug-89 0440 jinx@hpesogg.hp.com multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 04:40:39 PDT
Received: from sde.hp.com ([15.255.152.2]) by life.ai.mit.edu (4.1/AI-4.10) id AA00828; Wed, 23 Aug 89 06:57:53 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA06357; Wed, 23 Aug 89 00:00:05 pdt
Message-Id: <8908230700.AA06357@sde.hp.com>
Received: by hpesogg; Tue, 22 Aug 89 23:51:29 pdt
Date: Tue, 22 Aug 89 23:51:29 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@life.ai.mit.edu, will@cs.uoregon.edu
In-Reply-To: R. Kent Dybvig's message of Tue, 22 Aug 89 22:45:40 -0500 <8908230345.AA08061@life.ai.mit.edu>
Subject: multiple values
Reply-To: jinx%hpesogg@sde.hp.com
And this is the feature I'm most critical of. Unless an implementation
does support the truncation feature, I don't see any reason why we should
require that "(values e)" be equivalent to "e". I would like to feel
free to signal an error if "(values e)" is returned to a context that
is not prepared to accept multiple values.
The question is whether you want to catch your personal errors, or you
want to catch everyone else's errors.
1) If you want to catch everyone else's errors, you don't gain
anything by making this additional restriction. No one but you, and I
suspect not even you, is going to write the following code:
(with-values
(lambda ()
<some code>)
(lambda (k) ; Single value expected
<more code>))
Given this, everyone (except perhaps you) will redefine values in the
following way:
(define (lax-values . all)
(if (not (singleton? all))
(apply values all)
(car all)))
Furthermore, if ACCEPTS? is in the language, people will do the
following
(define (lax-with-values generator recvr)
(if (not (arity-is-1? recvr))
(with-values generator recvr)
(let ((value (generator)))
(recvr value))))
Where
(define (singleton? list)
(and (pair? list)
(null? (cdr list))))
(define (arity-is-1? procedure)
(and (accepts? procedure 1)
(not (accepts? procedure 0))
(not (accepts? procedure 2))))
and you won't gain any error checking on everyone else's code.
[PS: I realize that lax-values above has a bug, but it will do for
most people. The bug can be fixed with ACCEPTS? in the following way:
(define (lax-values . all)
(if (not (singleton? all))
(apply values all)
(call-with-current-continuation
(lambda (k)
(if (arity-is-1? k)
(car all)
(apply values all))))))
]
2) If you want to catch your own errors, you (personally) can use the
following versions instead:
(define (dyb-with-values generator recvr)
(with-values generator
(lambda all
(if (< (length all) 2)
(error "dyb-with-values: Mismatch" all)
(apply recvr (cddr all))))))
(define (dyb-values . all)
(apply values (cons 'ignore-0 (cons 'ignore-1 all))))
∂23-Aug-89 0458 ramsdell@linus.mitre.org Just add WITH-VALUES and VALUES.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 04:58:20 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA01612; Wed, 23 Aug 89 07:39:26 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA18144; Wed, 23 Aug 89 07:33:06 EDT
Posted-Date: Wed, 23 Aug 89 07:33:02 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA09643; Wed, 23 Aug 89 07:33:03 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908231133.AA09643@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Just add WITH-VALUES and VALUES.
In-Reply-To: Your message of Tue, 22 Aug 89 15:12:00 -0400.
<19890822191226.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Wed, 23 Aug 89 07:33:02 EDT
I sounds to me like the WITH-VALUES is the preferred name and the
generator should be the first argument to WITH-VALUES. So here is my
amended proposal.
------------------------------ WITH-VALUES Proposal.
(values obj ...) essential procedure
Returns 0 or more values to a receiving procedure (See with-values).
(values) => returns zero (no) values
(values 1) => returns a single value, 1
(values 1 'a) => returns two values, 1 and the symbol a
(with-values generator receiver) essential procedure
Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with no arguments. It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator' or if 'generator' cannot be called with zero arguments.
(with-values
(lambda ()
(values 1 2))
cons) => (1 . 2)
--------------------------------
As for the politics, consider this proposal as the best oportunity for
a compromise. We ask Kent Dybvig to accept the critical property that
(VALUES E) is always equivalent to E and we ask Guillermo Rozas to
accept no agreement can currently be reached about an arity checking
procedure. Please do not hold WITH-VALUES and VALUES hostage for they
really do represent existing practice, and many programmers use these
procedures. The art of politics is compromise. What say we give it a try?
John
PS. My preferred name for WITH-VALUES is CPS-CALL, but I would not
let the preferrence stand in the way of a compromise!
∂23-Aug-89 0458 jinx@hpesogg.hp.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 04:57:10 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA01635; Wed, 23 Aug 89 07:40:25 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA04990; Tue, 22 Aug 89 23:13:16 pdt
Message-Id: <8908230613.AA04990@sde.hp.com>
Received: by hpesogg; Tue, 22 Aug 89 23:12:31 pdt
Date: Tue, 22 Aug 89 23:12:31 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: R. Kent Dybvig's message of Tue, 22 Aug 89 22:31:06 -0500 <8908230330.AA02675@sde.hp.com>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com
As long as we are considering the issues politically rather than
technically, how would you feel about the following compromises?
* let's add "values" and "with-values" (or "apply-values") and
change the name of the so-called "named let" to "recur".
Clearly these are independent issues. The issues with multiple values
are not. I PERSONALLY find multiple values useless (other people
obviously disagree) if they don't give me the capability that I want.
I don't think you can link named let to multiple values in a similar
way.
* let's add "accepts?" and remove the requirement that Scheme
be case insensitive.
Again, you are being random. I can offer you many of these random
compromises too (how about trading "named let" -> "recur" for "begin"
-> "progn" ?).
∂23-Aug-89 0508 jinx@hpesogg.hp.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 05:08:39 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA01856; Wed, 23 Aug 89 07:49:18 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA04907; Tue, 22 Aug 89 23:08:46 pdt
Message-Id: <8908230608.AA04907@sde.hp.com>
Received: by hpesogg; Tue, 22 Aug 89 23:08:03 pdt
Date: Tue, 22 Aug 89 23:08:03 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: R. Kent Dybvig's message of Tue, 22 Aug 89 22:15:25 -0500 <8908230314.AA02393@sde.hp.com>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com
There is a difference that I'm surprised you don't see. When "pair?"
returns #t for an object, I know that I can use "car" or "cdr" without
causing an error. No similar claim can be made for "accepts?".
There is an analogy that I'm surprised you don't see: :-)
Just because (pair? x) is #t, I can't guarantee that (cddr x) won't
error.
Similarly, just because (accepts? p 3) evaluates to #t I can't guarantee
that (accepts? cons 3) even if
(define (p . args)
(apply cons args))
As another example, you would certainly say that I was being confused
if I complained about the following program signalling an error
(define (foo x y)
(if (and (list? x) (> (length x) 1))
(begin
(set-cdr! x y)
(cddr x))))
(foo (list 1 2) 'joe)
Further processing after initial invocation is not guaranteed to be
correct. It depends on exactly what the program does.
Your argument seems to be that ACCEPTS? is an ill-defined concept
because when we actually give that many arguments the process may
still error out (for example if the types or range of the arguments
are incorrect).
Accepts? is not a general purpose error-hook. It does not attempt to
find out whether a given process will terminate or error out. It is
just telling me whether the signature of a given procedure object (not
the corresponding mathematical function) is such that it is legal to
give it 3 arguments. It is almost "syntactic".
If we decide to add "accepts?" to the language, we would have to say
that an implementation is free to return #t if it cannot determine
whether or not a given number of arguments is accepted by a given
procedure. An implementation might even define "accepts?" as:
Again, if you don't try to make it transitive, and a Turing oracle, it
is perfectly well defined whether a given procedure object accepts a
given number of arguments or not. I would be very annoyed (and
consider the implementation to be in error) if
(accepts? p 3) -> #t
and then
(p 'a 'b 'c) -> Error from apply: Too many (or few) arguments to p
It is perfectly fine if
(accepts? p 3) -> #t
and then
(p 'a 'b 'c) -> Error from apply: Too many (or few) arguments to q
where (eqv? p q) -> #f
The further constraint that is needed to make me happy is that
(define (check-2 n)
(with-values
(lambda ()
(call-with-current-continuation
(lambda (cont)
(values (accepts? cont n) 'ignore))))
(lambda (x y)
x)))
(check-2 2) -> #t
(and (integer? m)
(not (negative? m))
(not (= m 2))
(check-2 m)) -> #f
For all objects m.
Analogously for check-0, check-1, check-3, etc.
∂23-Aug-89 0853 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 08:51:28 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA03979; Wed, 23 Aug 89 11:29:46 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26520;
22 Aug 89 13:25 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Aug 89 13:25:21 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa26446;
22 Aug 89 13:19 EDT
Received: from fafnir.think.com by Think.COM; Tue, 22 Aug 89 13:19:24 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 22 Aug 89 13:16:52 EDT
Received: by verdi.think.com; Tue, 22 Aug 89 13:16:40 EDT
Date: Tue, 22 Aug 89 13:16:40 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8908221716.AA01133@verdi.think.com>
To: bawden.pa@xerox.com
Cc: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: bawden.pa@xerox.com's message of Mon, 21 Aug 89 17:24 PDT <19890822002405.2.ALAN@ROCKY.parc.xerox.com>
Subject: Numbers
Date: Mon, 21 Aug 89 17:24 PDT
From: bawden.pa@xerox.com
Date: Mon, 21 Aug 89 11:34:37 EDT
From: Guy Steele <gls@think.com>
I'm back from an exhausting, and therefore very restful, vacation.
Back into the fray!
I was wondering why I hadn't heard from you. I couldn't imagine that you
had given up the argument!
Here is a new proposal. Given a set of points within a partial order,
there are two interesting kinds of "max"-like operation. One is to find
some point (not necessarily within the set) that is >= all points in the
given set; this is SUP....
Another is to find some point in the set such that no point in the set is >
that point....
But the version of MAX I am advocating isn't either of these! I would
allow:
(max 1.0 549755813889) ==> 549755813888.0
Where presumably (< 549755813888.0 549755813889) is true. Thus MAX can
return an object that, according to `<', is smaller than one of the
arguments.
Now I'm sure that about half of you are shouting at your terminal about how
I couldn't -possibly- mean that, but I do. Understand me once and for all:
INEXACT NUMBERS ARE NOT NUMBERS
INEXACT NUMBERS ARE NOT NUMBERS
INEXACT NUMBERS ARE NOT NUMBERS
They do not obey the rules followed by numbers, because they cannot.
Inexact numbers only represent our -approximate- -knowledge- about numbers.
In
(max 1.0 549755813889) ==> 549755813888.0
we strongly suspect that the first number is 1, but we don't know for sure.
Thus we strongly suspect that the answer is 549755813889, but again we
don't know for sure (the first number could have actually been
549755813890). Since we don't know the answer for sure, we must return an
inexact representation of our best guess. 549755813888.0 is the closest we
can come. (The next larger might be 549755879424.0, assuming 23 bits of
floating point precision, which is not very close at all.)
Indeed, we could -specify- that MAX always ``round up'' in the inexact case
so that the result always appears greater (accroding to `<') than any of
the arguments. This would be similar to specifying that `<' must always
behave transitively. It would be a feeble attempt on our part to paper
over the ugly fact that -in- -general-, inexact numbers do not obey the
axioms of arithmetic.
I did misunderstand. Thank you for correcting me on this point. Now:
Pardon my French, but this is completely ridiculous. You are telling me
that if I compare the height of a skyscraper, accurately measured by laser
and known to be within a few microns of 1000 feet tall, with a little kid
judged by eyeball to be within four inches of three feet tall, then I
should conclude that I know the larger of the two heights to be 1000 feet
but only to within four inches.
I agree that in *some* cases the best you can do is return an inexact
representation of one's best guess. But sometimes you can tell for sure
that the answer is exact, even if some of the inputs were inexact.
In other words, I deny that the inexactness contagion used for + and * is
appropriate for MAX and MIN. Why is 549755813888.0 the closest we can
come? Only because we have made an arbitrary decision to cast the result
into a representation that reflects the inexactness of the least exact
input, regardless of whether that amount of inexactness in fact had
anything to do with the result computed.
--Guy
∂23-Aug-89 0856 @mc.lcs.mit.edu:bawden.pa@xerox.com Numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 08:55:52 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04029; Wed, 23 Aug 89 11:33:38 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01876;
22 Aug 89 18:09 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Aug 89 17:48:20 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa01446; 22 Aug 89 17:43 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 22 AUG 89 14:43:10 PDT
Date: Tue, 22 Aug 89 14:40 PDT
From: bawden.pa@xerox.com
Subject: Numbers
To: gls@think.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8908221716.AA01133@verdi.think.com>
Message-Id: <19890822214016.5.ALAN@ROCKY.parc.xerox.com>
Line-Fold: no
Date: Tue, 22 Aug 89 13:16:40 EDT
From: gls@Think.COM (Guy Steele)
Pardon my French, but this is completely ridiculous.
I keep hoping that if I rattle you hard enough I may be able to shake you
loose from your position. Perhaps I'm making progress...
You are telling me
that if I compare the height of a skyscraper, accurately measured by laser
and known to be within a few microns of 1000 feet tall, with a little kid
judged by eyeball to be within four inches of three feet tall, then I
should conclude that I know the larger of the two heights to be 1000 feet
but only to within four inches.
Inexact numbers do not necessarily contain a representation of the
precision with which a quantity is known. In the common case where
floating point is used, they most definitely do not. (In the rare case
where interval arithmetic is used, the bounds are known.) Thus in a
floating point implementation of inexact numbers, you cannot represent the
concepts of "within a few microns of 1000 feet" or "within four inches of
three feet". The best you can do is "perhaps 1000 feet" and "about four
feet". The MAX of these two is "perhaps 1000 feet" -- any arguments about
the precision ("within a few microns of 1000 feet" vs. "within four inches
of 1000 feet") are in the province of a numerical analyst to reason about.
What I was -actually- claiming was that the MAX of "exactly 1000 feet" and
"about four feet" is "perhaps 1000 feet". (In an implementation that used
interval arithmetic, I could indeed compute the MAX of "exactly 1000 feet"
and "within four inches of three feet" and get "exactly 1000 feet", but in
-general-, inexact arithmetic does not have this ability.)
I agree that in *some* cases the best you can do is return an inexact
representation of one's best guess. But sometimes you can tell for sure
that the answer is exact, even if some of the inputs were inexact.
Perhaps a numerical analyst can look at my program and tell me that for
sure. Perhaps if I am using interval arithmetic my implementation can tell
me that for sure. But if I am using floating point, my implementation can
-never- know that for sure.
In other words, I deny that the inexactness contagion used for + and * is
appropriate for MAX and MIN. Why is 549755813888.0 the closest we can
come? Only because we have made an arbitrary decision to cast the result
into a representation that reflects the inexactness of the least exact
input, regardless of whether that amount of inexactness in fact had
anything to do with the result computed.
It was not an "arbitrary decision" at all. 549755813888.0 is closest
because we only have 23-bit floating point to represent inexact numbers,
and the answer must be inexact. Its the best we can do. If we return an
exact number we are potentially returning an -INCORRECT- result. We don't
know the answer exactly, so we cannot return an exact number.
I would have no objection if we decided to specify that MAX would have to
round up, so that 549755879424.0 was the answer in my example. One could
argue that this was somehow a better approximation to the true answer
because it passed the `<' test. But under no circumstances can I see
allowing 549755813889 to be returned, as that would discard the important
information that the answer is not known exactly.
∂23-Aug-89 0905 dyb@iuvax.cs.indiana.edu Re: multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 09:05:46 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04104; Wed, 23 Aug 89 11:40:55 EDT
Message-Id: <8908231540.AA04104@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Wed, 23 Aug 89 10:41:22 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: jinx%hpesogg@sde.hp.com
Subject: Re: multiple values
Cc: rrrs-authors@life.ai.mit.edu
The question is whether you want to catch your personal errors, or you
want to catch everyone else's errors.
As an implementor, I would like to signal an error whenever someone
attempts to return (values ...) to a context where multiple values
aren't expected, or something other than (values ...) to a context
expecting multiple values. Requiring "(values e)" to be the same as
"e" makes it impossible to do this. As you pointed out in your note,
this won't affect anyone who doesn't like this behavior, since they
can always create their own versions of "values" and "with-values"
that circumvent the error checks.
Note that I'm not asking for a requirement that "(values e)" be
distinct from "e", only that we not require that "(values e)" be
the same as "e". So it doesn't rule out an implementation that
automatically truncates multiple values.
Kent
∂23-Aug-89 0925 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #180
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 09:25:07 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA03917; Wed, 23 Aug 89 11:21:58 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06320;
17 Aug 89 10:36 EDT
Date: 17 AUG 89 09:39:51 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Subject: Scheme Digest #180
To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id: <8908171037.aa06320@mintaka.lcs.mit.edu>
Scheme Digest #180 17 AUG 89 09:39:51 EDT
Today's Topics:
Lisp shells
Books on Scheme
Books on Scheme
Additional function libraries for PC-Scheme...
X Scheme availability
"Scheme has data types and Lisp doesn't."
----------------------------------------------------------------------
Date: Wed, 16 Aug 89 05:16:39 EDT
From: Olin.Shivers@a.gp.cs.cmu.edu
Subject: Lisp shells
Message-ID: <8908160517.aa18074@mintaka.lcs.mit.edu>
John Lacey requested information on Lisp shells. John Ellis implemented
a shell for a PDP-11/45 running Unix in Harvard Lisp in 1979.
"A LISP SHELL"
John R. Ellis
ACM SIGPLAN Notices, Vol. 15 #5, May 1980
John Levine has a paper about using Lisp for a command language in the
same issue of SIGPLAN Notices ("Why a Lisp-Based Command Language?").
Of course, you might do well to look into the Lisp Machine interface, both
before and after the fancy Symbolics interface that allowed non-Lisp-syntax
commands. Any you might consider gnu-emacs plus all the extensions (like
monkey mode) to be a fairly reasonable shell, with lisp as an extension
language.
-Olin
------------------------------
Date: 15 Aug 89 17:43:18 GMT
From: Jonas 'Gamemaster' Mellin <mcvax!sunic!his!jonas@uunet.uu.net>
Subject: Books on Scheme
Message-Id: <261@his.UUCP>
Does anyone know a good book about Scheme?
Please answer via E-mail.
------------------------------
Date: 16 Aug 89 14:58:49 GMT
From: Adam Glass <adam@media-lab.media.mit.edu>
Subject: Re: Books on Scheme
Message-Id: <493@mit-amt.MEDIA.MIT.EDU>
jonas@his.UUCP (Jonas 'Gamemaster' Mellin) writes:
> Does anyone know a good book about Scheme?
>
> Please answer via E-mail.
Please answer via a public message in this newsgroup. I am quite interested
also.
Adam
--
"Offer me anything I ask for..."
"Anything you want."
"I want my father back, you son of a bitch." - The Princess Bride
------------------------------
Date: 16 Aug 89 15:28:04 GMT
From: Kevin Spier <usc!cs.utexas.edu!csd4.csd.uwm.edu!leah!rpi!turing.cs.rpi.edu!spierk@bloom-beacon.mit.edu>
Subject: Additional function libraries for PC-Scheme...
Message-Id: <6802@rpi.edu>
I am looking for any public domain function libraries (in source form
only) available for PC Scheme v3.0 (which is R↑3 compatible). I guess
any library which requires only R↑3 compatibility would also be fine.
Please mail directly to me and I will post a summary if others are
interested.
Thanks,
Kevin L. Spier
spierk@turing.cs.rpi.edu
Kevin L. Spier
spierk@turing.cs.rpi.edu
------------------------------
Date: 16 Aug 89 20:29:17 GMT
From: Erik Talvola <pasteur!talvola@ucbvax.berkeley.edu>
Subject: X Scheme availability
Message-Id: <TALVOLA.89Aug16132917@janus.berkeley.edu>
I have a rather old version of X-Scheme on my IBM PC (version 0.16) and
was wondering where I could obtain the most recent version, in both source
and object form. Availability by FTP would be nice, but if not, then a
BBS source would be fine. Thanks in advance.
--
+----------------------------+
! Erik Talvola | "It's just what we need... a colossal negative
! talvola@janus.berkeley.edu | space wedgie of great power coming right at us
! ...!ucbvax!janus!talvola | at warp speed." -- Star Drek
------------------------------
Date: 15 Aug 89 14:52:37 GMT
From: Jeff Dalton <mcvax!ukc!edcastle!aiai!jeff@uunet.uu.net>
Subject: Re: "Scheme has data types and Lisp doesn't."
Message-Id: <737@skye.ed.ac.uk>
In article <13120@well.UUCP> nagle@well.UUCP (John Nagle) writes:
>Common LISP has lots of declarations. But the programmer isn't required
>to provide them and the compiler implementor isn't required to make them
>do much. CLTL: [...] Not that SCHEME is really all that different.
I knew about all of the things you cite in CLtL. I still don't see
how it explains the claim that "Scheme has data types and Lisp doesn't."
-- Jeff
------------------------------
End of Scheme Digest
********************
∂23-Aug-89 0939 dyb@iuvax.cs.indiana.edu Re: Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 09:39:03 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04605; Wed, 23 Aug 89 12:27:20 EDT
Message-Id: <8908231627.AA04605@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Wed, 23 Aug 89 11:27:42 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: jinx%hpesogg@sde.hp.com
Subject: Re: Multiple values for R4RS.
Cc: rrrs-authors@life.ai.mit.edu
There is an analogy that I'm surprised you don't see: :-)
Just because (pair? x) is #t, I can't guarantee that (cddr x) won't
error.
Ah, but I can ask (and (pair? x) (pair? (cdr x))), and if this is #t,
then I can be certain that (cddr x) won't error.
Similarly, just because (accepts? p 3) evaluates to #t I can't guarantee
that (accepts? cons 3) even if
(define (p . args)
(apply cons args))
That's right.
Further processing after initial invocation is not guaranteed to be
correct. It depends on exactly what the program does.
Right again.
Your argument seems to be that ACCEPTS? is an ill-defined concept ...
My argument is that "accepts?" is virtually meaningless, since it is
a superficial property of the outermost level of the procedure, and there
is no way to extend it further in. If "accepts?" returns #t, so what?
Again, if you don't try to make it transitive, and a Turing oracle, it
is perfectly well defined whether a given procedure object accepts a
given number of arguments or not. I would be very annoyed (and
consider the implementation to be in error) if
(accepts? p 3) -> #t
and then
(p 'a 'b 'c) -> Error from apply: Too many (or few) arguments to p
But this is exactly what may happen if "p" does its own checking, i.e.,
if I write p as:
(lambda args
(if (> (length args) 2)
(error 'apply "Too many (or few) arguments to p")
(f args)))
Of course, "p" is representing itself as "apply" in the error message,
but I hardly see that it's relevant where the message comes from.
∂23-Aug-89 1027 mkatz%sesame.stanford.edu@relay.cs.net Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 10:27:37 PDT
Received: from MIT.EDU (MIT.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA05110; Wed, 23 Aug 89 13:09:16 EDT
Received: from RELAY.CS.NET by MIT.EDU with SMTP
id AA03906; Wed, 23 Aug 89 13:09:05 EDT
Received: from sesame.stanford.edu by RELAY.CS.NET id aa01216;
23 Aug 89 13:08 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00319; Wed, 23 Aug 89 10:07:34 PDT
Date: Wed, 23 Aug 89 10:07:34 PDT
From: Morris Katz <mkatz%sesame.stanford.edu@relay.cs.net>
Message-Id: <8908231707.AA00319@sesame.Stanford.EDU>
To: adams%tekchips.labs.tek.com@relay.cs.net
Cc: jinx%hpesogg@sde.hp.com, mkatz%sesame.stanford.edu@relay.cs.net,
rrrs-authors%life.ai.mit.edu@relay.cs.net, adams@tekchips.labs
In-Reply-To: Norman Adams's message of Tue, 22 Aug 89 17:14:03 PDT <8908230014.AA26483@tekchips.LABS.TEK.COM>
Subject: Multiple values for R4RS.
Date: Tue, 22 Aug 89 17:14:03 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
From: mkatz%sesame.stanford.edu
I can't imagine how one could create an implementation in which the arity
information is not already present in some form for procedures that
are passed
Sure, it is present in some form.
Perhaps each procedure is responsible for coping with wrong number of
arguments passed in. Somewhere in the procedure's code are
instructions that perform the check. The information is there, but
with a sufficiently clever compiler -- the sort of implementation I
find most interesting -- finding that information could be
impractical, if not intractable.
Difficult maybe; intractable, I doubt. I think this same argument could be
given for eliminating continuations from Scheme as they create restrictions on
implementation methodologies. There is almost always a tradeoff between
graeter functionality and implementation simplicity. I, for one, think that
the functionality gained by adding ACCEPTS? justifies its complexity. To
convince me otherwise I am afraid you are going to have to be more specific
about why a good compiler gets screwed by accepts. It seems to me that a good
compiler should only pay a cost for ACCEPTS? when it is used (as Jinx has
stated). Isn't this the ideal characterization of a feature? It only costs
the user when they use it.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂23-Aug-89 1102 cph@zurich.ai.mit.edu Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 11:02:35 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA05337; Wed, 23 Aug 89 13:24:31 EDT
Received: from localhost by zurich.ai.mit.edu; Wed, 23 Aug 89 13:21:17 edt
Date: Wed, 23 Aug 89 13:21:17 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8908231721.AA07769@zurich.ai.mit.edu>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: R. Kent Dybvig's message of Wed, 23 Aug 89 11:27:42 -0500 <8908231627.AA04605@life.ai.mit.edu>
Subject: Multiple values for R4RS.
Date: Wed, 23 Aug 89 11:27:42 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
Your argument seems to be that ACCEPTS? is an ill-defined concept ...
My argument is that "accepts?" is virtually meaningless, since it is
a superficial property of the outermost level of the procedure, and there
is no way to extend it further in. If "accepts?" returns #t, so what?
(Here is yet another chapter in the war between the theoreticians and
the engineers.)
Because the proposed semantics of `accepts?' does not return the
"correct" answer 100% of the time, Kent is unwilling to accept it.
Indeed, it is not possible to determine the "correct" answer because
of the halting problem. Yet at the same time, the proposed semantics
is sufficient to solve what Jinx sees as a real problem.
My summary of these arguments is that Kent is rejecting `accepts?'
because it doesn't satisfy a specification which is known to be
impossible to satisfy. I believe this is an unreasonable position,
and we should move on to a more substantive argument. I've heard two
of these:
1. `accepts?' is not very useful. (I agree with Jinx, having used MIT
Scheme's version of this predicate for about a year or so. In
practice, I find that the counterexamples Kent has presented are not
too common.)
2. `accepts?' places an unreasonable burden on the implementor. (I
concede that this -might- be true, but that is a judgment of the
usefulness of `accepts?' as well as its implementation cost.)
∂23-Aug-89 1104 KMP@stony-brook.scrc.symbolics.com Re: Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 11:03:15 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM by life.ai.mit.edu (4.1/AI-4.10) id AA05149; Wed, 23 Aug 89 13:12:44 EDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 645502; 22 Aug 89 15:12:28 EDT
Date: Tue, 22 Aug 89 15:12 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: Re: Multiple values for R4RS.
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, KMP@stony-brook.scrc.symbolics.com
In-Reply-To: <8908221800.AA08733@huxley.mitre.org>
Message-Id: <19890822191226.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
[1] Do you think VALUES and APPLY-VALUES as defined are controversial?
Yes.
[2] Do you think VALUES and APPLY-VALUES as defined reflect existing
practice?
Yes.
[3] Do you think VALUES and APPLY-VALUES as defined prohibit the
future inclusion of ACCEPTS? or some other proposal to deal with
incompatiable arities?
No, though this seems somewhat irrelevant.
[4] Do you believe VALUES and APPLY-VALUES should be excluded from
Scheme solely because there is no agreement on how to deal with
incompatiable arities?
No.
For what it's worth, I would not endorse the inclusion of VALUES and
APPLY-VALUES as proposed. Here are my suggestions for correcting it:
I would invert the order of arguments. I think this will feel more
natural. APPLY, normal function call, MAP, etc. all work this way.
If you cannot bring yourself to change the order, you should definitely
remove the morpheme `APPLY' to avoid confusion with argument conventions
for the APPLY function. Programmers are likely to model the
values-yielding argument to APPLY-VALUES as a generalized variant of the
list-to-spread last argument to APPLY, and then to wonder why the two
functions take their `other' argument in opposite places.
In fact, I think this function is more closely related to
CALL-WITH-CURRENT-CONTINUATION than to APPLY, and that the naming should
reflect that. I think a name like CALL-WITH-RESULTING-VALUES (or just
CALL-WITH-VALUES, though that's less descriptive) would be better.
In effect, what this operator does is to splice a new function into the
continuation chain. As such, something like INTERPOSE-CONTINUATION or
ENCAPSULATE-CURRENT-CONTINUATION (well, not quite) or
COMPOSE-CURRENT-CONTINUATION (my personal favorite, for `symmetry' with
T's COMPOSE) would also be appropriate.
RECEIVE-VALUES is clearly better than APPLY-VALUES in my mind, but it
still leaves you feeling like it should be a special form that magically
picks up values resulting from the second form, rather than something
which takes a normal functional argument. That's the main reason why I
think something with the morpheme `CONTINUATION' in it would be best.
Although these are syntactic rather than semantic issues, I consider
them important to get right. But modulo the syntax stuff, I strongly
favor the introduction of the proposed level of functionality into R4RS.
By the way, while I'm at it, I don't much like the name VALUES because
it looks yucky for the 1-argument case. Since RETURN is problematic, I
think I would prefer YIELD over VALUES. But I can live with either if
it comes to it.
Also, regarding ACCEPTS?, just so I'm on the record about it, I think a
predicate that took a continuation (or even an arbitrary function) and
an integer and told you if that number of arguments was suitable. I
think the name ACCEPTS? is too short and too general for so specific a
purpose. I would rather a longer, less generic sounding name. But I
have no conflict with the idea of this kind of functionality.
∂23-Aug-89 1104 mkatz@sesame.stanford.edu multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 11:04:26 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA05385; Wed, 23 Aug 89 13:28:16 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00373; Wed, 23 Aug 89 10:26:39 PDT
Date: Wed, 23 Aug 89 10:26:39 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8908231726.AA00373@sesame.Stanford.EDU>
To: dyb@iuvax.cs.indiana.edu
Cc: jinx%hpesogg@sde.hp.com, rrrs-authors@life.ai.mit.edu
In-Reply-To: R. Kent Dybvig's message of Wed, 23 Aug 89 10:41:22 -0500 <8908231540.AA04104@life.ai.mit.edu>
Subject: multiple values
Date: Wed, 23 Aug 89 10:41:22 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
Note that I'm not asking for a requirement that "(values e)" be
distinct from "e", only that we not require that "(values e)" be
the same as "e". So it doesn't rule out an implementation that
automatically truncates multiple values.
I must be missing something. How does the requirement that "(values e)" and
"e" be the same rule out an implementation the automatically truncates?
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂23-Aug-89 1105 mkatz@sesame.stanford.edu multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 11:04:49 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA05301; Wed, 23 Aug 89 13:22:30 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00363; Wed, 23 Aug 89 10:21:04 PDT
Date: Wed, 23 Aug 89 10:21:04 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8908231721.AA00363@sesame.Stanford.EDU>
To: will@cs.uoregon.edu
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Tue, 22 Aug 89 18:07:02 PDT <8908230107.AA29487@spencer.cs.uoregon.edu>
Subject: multiple values
Date: Tue, 22 Aug 89 18:07:02 PDT
From: will@cs.uoregon.edu
Passing an incorrect number of arguments to a procedure isn't required to
signal an error, so procedures don't have to check it.
You are correct. I forgot that arity mismatches don't necessarily signal an
error.
Also, why should
the run-time representation of (lambda args #t) include any bits that
indicate the number of arguments it expects?
Assuming that an implementation does put in checks for the wrong number of
args, then, at least in theory, one could parse the code to find the arity
information. This might be a pain in the butt; but, at least in theory, it is
possible. In those cases where the code does not need to check arity because
it was determined not to be necessary at compile time, the answer to an
ACCEPTS? query should also be decidable at compile time. (I wasn't suggesting
this implementation, but only pointing out that an implementation exists which
has essentially zero runtime cost when ACCEPTS? is not used.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂23-Aug-89 1118 mkatz@sesame.stanford.edu Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 11:14:26 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA05552; Wed, 23 Aug 89 13:37:22 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00404; Wed, 23 Aug 89 10:36:16 PDT
Date: Wed, 23 Aug 89 10:36:16 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8908231736.AA00404@sesame.Stanford.EDU>
To: dyb@iuvax.cs.indiana.edu
Cc: jinx%hpesogg@sde.hp.com, rrrs-authors@life.ai.mit.edu
In-Reply-To: R. Kent Dybvig's message of Tue, 22 Aug 89 22:15:25 -0500 <8908230314.AA07736@life.ai.mit.edu>
Subject: Multiple values for R4RS.
Date: Tue, 22 Aug 89 22:15:25 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
If we decide to add "accepts?" to the language, we would have to say
that an implementation is free to return #t if it cannot determine
whether or not a given number of arguments is accepted by a given
procedure. An implementation might even define "accepts?" as:
(lambda (procedure arity) #t)
This may seem to water down the predicate, but it only makes explicit
that which must already be true.
Please explain in what cases you believe ACCEPTS? is inherently undecidable.
The above message implies there are such cases, but they are not obvious to me.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂23-Aug-89 1118 @relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 11:18:14 PDT
Received: from MIT.EDU (MIT.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA05622; Wed, 23 Aug 89 13:44:22 EDT
Received: from RELAY.CS.NET by MIT.EDU with SMTP
id AA03922; Wed, 23 Aug 89 13:44:11 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa02594; 23 Aug 89 13:44 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA22985; Wed, 23 Aug 89 10:46:22 PDT
Received: by tekirl.labs.tek.com (5.51/7.1)
id AA21911; Wed, 23 Aug 89 10:44:15 PDT
Received: by tekchips.LABS.TEK.COM (5.51/6.24)
id AA00958; Wed, 23 Aug 89 10:46:45 PDT
Date: Wed, 23 Aug 89 10:46:45 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Message-Id: <8908231746.AA00958@tekchips.LABS.TEK.COM>
To: jinx%hpesogg@sde.hp.com
Cc: rrrs-authors%life.ai.mit.edu@relay.cs.net
In-Reply-To: "Guillermo J. Rozas"'s message of Tue, 22 Aug 89 23:12:31 pdt <8908230613.AA04990@sde.hp.com>
Subject: Multiple values for R4RS.
I PERSONALLY find multiple values useless (other people
obviously disagree) if they don't give me the capability that I want.
When someone on this list argues for a change or addition to the
report, I assume they are implicitly asserting that they think such a
change or addition would be for the greater good, and not just to
satisfy some idiosyncrasy.
Identifying something as personal, tends to cut off discussion,
because, after all, you are entitled to your own personal opinion. If
you want to change your position on a proposal, I would prefer that
you do so explicitly.
-Norman
∂23-Aug-89 1126 jar@zurich.ai.mit.edu Just add WITH-VALUES and VALUES.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 11:25:59 PDT
Received: from zurich.ai.mit.edu ([18.43.0.158]) by life.ai.mit.edu (4.1/AI-4.10) id AA05623; Wed, 23 Aug 89 13:44:45 EDT
Received: from localhost by zurich.ai.mit.edu; Wed, 23 Aug 89 13:41:29 edt
Date: Wed, 23 Aug 89 13:41:29 edt
From: jar@zurich.ai.mit.edu (Jonathan Rees)
Message-Id: <8908231741.AA00810@zurich.ai.mit.edu>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: ramsdell@linus.mitre.org's message of Wed, 23 Aug 89 07:33:02 EDT <8908231133.AA09643@huxley.mitre.org>
Subject: Just add WITH-VALUES and VALUES.
From: ramsdell@linus.mitre.org
Date: Wed, 23 Aug 89 07:33:02 EDT
As for the politics, consider this proposal as the best opportunity
for a compromise. We ask Kent Dybvig to accept the critical
property that (VALUES E) is always equivalent to E and we ask
Guillermo Rozas to accept no agreement can currently be reached
about an arity checking procedure. Please do not hold WITH-VALUES
and VALUES hostage for they really do represent existing practice,
and many programmers use these procedures. The art of politics is
compromise. What say we give it a try?
I agree. I don't see why every language change has to be a matter of
life and death. These questions are just not so important that the
discussions have to raise so much animosity. It's very depressing to
see so little interest in compromise. Why can't y'all just relax a
little?
∂23-Aug-89 1126 jar@zurich.ai.mit.edu Just add WITH-VALUES and VALUES.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 11:25:56 PDT
Received: from zurich.ai.mit.edu ([18.43.0.158]) by life.ai.mit.edu (4.1/AI-4.10) id AA05683; Wed, 23 Aug 89 13:55:07 EDT
Received: from localhost by zurich.ai.mit.edu; Wed, 23 Aug 89 13:51:53 edt
Date: Wed, 23 Aug 89 13:51:53 edt
From: jar@zurich.ai.mit.edu (Jonathan Rees)
Message-Id: <8908231751.AA00815@zurich.ai.mit.edu>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: ramsdell@linus.mitre.org's message of Wed, 23 Aug 89 07:33:02 EDT <8908231133.AA09643@huxley.mitre.org>
Subject: Just add WITH-VALUES and VALUES.
I like the brevity of your proposal, but the proposal should
explicitly say something about what the arity of implicit
continuations (into argument positions for calls, test position of if,
etc.) is. I.e. whether (list (foo)) is equivalent to
(list (with-values foo (lambda (x) x)))
or
(list (with-values foo (lambda (x . ignore) x)))
or something else. As I remember, the near-consensus at Snowbird was
for the second. (That was also the near-consensus at the MIT meeting
of 1987 (?), except that I disagreed; I changed my position later when
I saw that I was outnumbered and when I could understand the semantics
of the other position better. Now I don't much care, I just would
like to see multiple values in some form.)
As long as I'm babbling, my problem with ACCEPTS? or
PROCEDURE-ACCEPTS? is that there is no inverse for it -- no general
way to construct a procedure that can advertise how many arguments it
would like to accept. In particular, it makes invalid Scheme's
currently useful eta-expansion rule: if x is a procedure, then x can
be replaced by (lambda args (apply x args)) [modulo EQ?]. We could
recover some kind of eta rule if we had some way to associate an
ACCEPTS? "method" with a procedure, e.g. maybe (ACCEPTING proc1 proc2)
would return a procedure p that behaved the same as proc1 except that
(ACCEPTS? p n) would return the value returned by (proc2 n).
(You can do this kind of thing in T, which has a crude analogue of
ACCEPTS?.) Then we would have x equivalent to
(accepting (lambda args (apply x args)) (lambda (n) (accepts? x n))).
I'm not proposing ACCEPTING, and I'm not saying that I would veto any
proposal that has ACCEPTS? in it.
∂23-Aug-89 1134 @relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 11:34:45 PDT
Received: from MIT.EDU (MIT.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA06023; Wed, 23 Aug 89 14:13:27 EDT
Received: from RELAY.CS.NET by MIT.EDU with SMTP
id AA03968; Wed, 23 Aug 89 14:13:14 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa04046; 23 Aug 89 14:12 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA23836; Wed, 23 Aug 89 11:14:47 PDT
Received: by tekirl.labs.tek.com (5.51/7.1)
id AA22493; Wed, 23 Aug 89 11:12:40 PDT
Received: by tekchips.LABS.TEK.COM (5.51/6.24)
id AA01183; Wed, 23 Aug 89 11:15:10 PDT
Date: Wed, 23 Aug 89 11:15:10 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Message-Id: <8908231815.AA01183@tekchips.LABS.TEK.COM>
To: jinx%hpesogg@sde.hp.com
Cc: dyb@iuvax.cs.indiana.edu, rrrs-authors%life.ai.mit.edu@relay.cs.net
In-Reply-To: "Guillermo J. Rozas"'s message of Tue, 22 Aug 89 23:12:31 pdt <8908230613.AA04990@sde.hp.com>
Subject: Multiple values for R4RS.
From: Kent
* let's add "accepts?" and remove the requirement that Scheme
be case insensitive.
From: Jinx
Again, you are being random. ..
You are ignoring Kent's point.
Using the orginal ground rules from Brandeis -- I don't know what the
ground rules are now -- if everyone wanted A and B, and not everyone
wanted C, then A and B would go in the report and those who wanted C
could have it in their implementations. You have taken the tactic of
getting C in the report by refusing to agree to A and B, but offering
to agree on A, B, and C together. You claim that having A and B
imposes something on you while trying to impose C on everyone else.
So now Kent is making similar offers about those C which he cares
about.
-Norman
∂23-Aug-89 1200 jinx@hpesogg.hp.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 12:00:18 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA06416; Wed, 23 Aug 89 14:42:49 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA26812; Wed, 23 Aug 89 11:41:43 pdt
Message-Id: <8908231841.AA26812@sde.hp.com>
Received: by hpesogg; Wed, 23 Aug 89 11:41:01 pdt
Date: Wed, 23 Aug 89 11:41:01 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: adams@tekchips.labs.tek.com
Cc: dyb@iuvax.cs.indiana.edu, rrrs-authors@life.ai.mit.edu
In-Reply-To: Norman Adams's message of Wed, 23 Aug 89 11:15:10 PDT <8908231815.AA01183@tekchips.LABS.TEK.COM>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com
You are ignoring Kent's point.
Using the orginal ground rules from Brandeis -- I don't know what the
ground rules are now -- if everyone wanted A and B, and not everyone
wanted C, then A and B would go in the report and those who wanted C
could have it in their implementations. You have taken the tactic of
getting C in the report by refusing to agree to A and B, but offering
to agree on A, B, and C together. You claim that having A and B
imposes something on you while trying to impose C on everyone else.
So now Kent is making similar offers about those C which he cares
about.
You are ignoring my position. I DON'T WANT multiple values UNLESS I
can truncate values conveniently. That does not mean that I require
the default be to truncate values, just that it be possible for me to
do so. Otherwise I personally find no use for multiple values, and
would rather not have them in the language at all.
∂23-Aug-89 1200 jinx@hpesogg.hp.com multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 12:00:33 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA06480; Wed, 23 Aug 89 14:45:08 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA26880; Wed, 23 Aug 89 11:44:50 pdt
Message-Id: <8908231844.AA26880@sde.hp.com>
Received: by hpesogg; Wed, 23 Aug 89 11:44:08 pdt
Date: Wed, 23 Aug 89 11:44:08 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: R. Kent Dybvig's message of Wed, 23 Aug 89 10:41:22 -0500 <8908231540.AA04104@life.ai.mit.edu>
Subject: multiple values
Reply-To: jinx%hpesogg@sde.hp.com
As an implementor, I would like to signal an error whenever someone
attempts to return (values ...) to a context where multiple values
aren't expected, or something other than (values ...) to a context
expecting multiple values. Requiring "(values e)" to be the same as
"e" makes it impossible to do this. As you pointed out in your note,
this won't affect anyone who doesn't like this behavior, since they
can always create their own versions of "values" and "with-values"
that circumvent the error checks.
Why do you consider (values <single expression>) to be returning
multiple values? It's very clearly returning one.
Your argument seems very similar to trying to distinguish between
(f x)
and
(apply f (list x))
To be consistent, you should want us to categorize procedures
according to whether they can be APPLY'ed (sic), and only allow
APPLY'able (sic) procedures to be APPLY'ed. Otherwise the
implementation should be allowed to signal an error.
∂23-Aug-89 1201 jinx@hpesogg.hp.com Just add WITH-VALUES and VALUES.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 12:01:20 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA06361; Wed, 23 Aug 89 14:39:13 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA26758; Wed, 23 Aug 89 11:38:55 pdt
Message-Id: <8908231838.AA26758@sde.hp.com>
Received: by hpesogg; Wed, 23 Aug 89 11:38:15 pdt
Date: Wed, 23 Aug 89 11:38:15 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Wed, 23 Aug 89 07:33:02 EDT <8908231133.AA09643@huxley.mitre.org>
Subject: Just add WITH-VALUES and VALUES.
Reply-To: jinx%hpesogg@sde.hp.com
As for the politics, consider this proposal as the best oportunity for
a compromise. We ask Kent Dybvig to accept the critical property that
(VALUES E) is always equivalent to E and we ask Guillermo Rozas to
accept no agreement can currently be reached about an arity checking
procedure. Please do not hold WITH-VALUES and VALUES hostage for they
really do represent existing practice, and many programmers use these
procedures. The art of politics is compromise. What say we give it a try?
In a compromise everyone gives in a little. I don't see you doing
that.
The semantics that I want is that extra values are truncated when
returned to implicit continuations. As a compromise, I accept strict
semantics as long as ACCEPTS? is provided. I'm trying to compromise,
you are trying to have me surrender.
∂23-Aug-89 1203 jinx@hpesogg.hp.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 12:02:51 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA06596; Wed, 23 Aug 89 14:50:34 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA27012; Wed, 23 Aug 89 11:50:19 pdt
Message-Id: <8908231850.AA27012@sde.hp.com>
Received: by hpesogg; Wed, 23 Aug 89 11:49:37 pdt
Date: Wed, 23 Aug 89 11:49:37 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: adams@tekchips.labs.tek.com
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: Norman Adams's message of Wed, 23 Aug 89 10:46:45 PDT <8908231746.AA00958@tekchips.LABS.TEK.COM>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com
When someone on this list argues for a change or addition to the
report, I assume they are implicitly asserting that they think such a
change or addition would be for the greater good, and not just to
satisfy some idiosyncrasy.
Excuse me, but over half the arguments on this list are based on
aesthetics. Perhaps I'm just more honest because I remind everyone
that it is exactly what I'm doing.
∂23-Aug-89 1235 @relay.cs.net,@gateway.think.com:gls@THINK.COM Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 12:35:45 PDT
Received: from MIT.EDU (MIT.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA06795; Wed, 23 Aug 89 15:04:44 EDT
Received: from RELAY.CS.NET by MIT.EDU with SMTP
id AA04040; Wed, 23 Aug 89 15:04:33 EDT
Received: from gateway.think.com by RELAY.CS.NET id aa06741; 23 Aug 89 15:04 EDT
Received: from fafnir.think.com by Think.COM; Wed, 23 Aug 89 15:04:52 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 23 Aug 89 15:02:18 EDT
Received: by verdi.think.com; Wed, 23 Aug 89 14:28:00 EDT
Date: Wed, 23 Aug 89 14:28:00 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8908231828.AA13190@verdi.think.com>
To: mkatz%sesame.stanford.edu@relay.cs.net
Cc: adams%tekchips.labs.tek.com@relay.cs.net, jinx%hpesogg@sde.hp.com,
ramsdell%linus.mitre.org@relay.cs.net,
rrrs-authors%life.ai.mit.edu@relay.cs.net
In-Reply-To: Morris Katz's message of Tue, 22 Aug 89 15:34:50 PDT <8908222234.AA00236@sesame.Stanford.EDU>
Subject: Multiple values for R4RS.
Date: Tue, 22 Aug 89 15:34:50 PDT
From: Morris Katz <mkatz%sesame.stanford.edu@relay.cs.net>
Date: Tue, 22 Aug 89 14:15:28 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
As an implementor, I would prefer not
to be committed to keeping around arity information for every
procedure.
I can't imagine how one could create an implementation in which the arity
information is not already present in some form for procedures that are passed
as arguments. Similarly, implicit continuations had better know something
about the number of values on which they intend to operate. Retrieving the
arity information may require some bit twiddling, but I suspect that the needed
information is always present in some form.
You could always walk down the machine language code, trying to figure
out which registers or stack slots it is touching in order to fetch arguments.
(This is not a claim of good engineering, just an existence proof.)
--Guy
∂23-Aug-89 1237 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 12:37:11 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA06989; Wed, 23 Aug 89 15:15:30 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa15740;
23 Aug 89 15:07 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 23 Aug 89 15:06:09 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa15732;
23 Aug 89 15:04 EDT
Received: from fafnir.think.com by Think.COM; Wed, 23 Aug 89 15:04:58 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 23 Aug 89 15:02:23 EDT
Received: by verdi.think.com; Wed, 23 Aug 89 14:25:31 EDT
Date: Wed, 23 Aug 89 14:25:31 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8908231825.AA13164@verdi.think.com>
To: bawden.pa@xerox.com
Cc: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: bawden.pa@xerox.com's message of Tue, 22 Aug 89 14:40 PDT <19890822214016.5.ALAN@ROCKY.parc.xerox.com>
Subject: Numbers
Date: Tue, 22 Aug 89 14:40 PDT
From: bawden.pa@xerox.com
...
Inexact numbers do not necessarily contain a representation of the
precision with which a quantity is known. In the common case where
floating point is used, they most definitely do not. (In the rare case
where interval arithmetic is used, the bounds are known.) Thus in a
floating point implementation of inexact numbers, you cannot represent the
concepts of "within a few microns of 1000 feet" or "within four inches of
three feet". The best you can do is "perhaps 1000 feet" and "about four
feet". The MAX of these two is "perhaps 1000 feet" -- any arguments about
the precision ("within a few microns of 1000 feet" vs. "within four inches
of 1000 feet") are in the province of a numerical analyst to reason about.
Okay, I'll grant that. But I inserted "within a few microns" one for the
sake of lending plausibility to my physical metaphor--possibly a rhetorical
mistake. My code example clearly involves "exactly 1000 feet".
What I was -actually- claiming was that the MAX of "exactly 1000 feet" and
"about four feet" is "perhaps 1000 feet". (In an implementation that used
interval arithmetic, I could indeed compute the MAX of "exactly 1000 feet"
and "within four inches of three feet" and get "exactly 1000 feet", but in
-general-, inexact arithmetic does not have this ability.)
I agree that in *some* cases the best you can do is return an inexact
representation of one's best guess. But sometimes you can tell for sure
that the answer is exact, even if some of the inputs were inexact.
Perhaps a numerical analyst can look at my program and tell me that for
sure. Perhaps if I am using interval arithmetic my implementation can tell
me that for sure. But if I am using floating point, my implementation can
-never- know that for sure.
Here is where the cart may be before the horse. I'll let you inspect the
*types* of the arguments up front in any case. Are you then deciding a
priori to use floating-point to represent the result only on the basis of
the argument types, without regard to the values involved? Or do you
entertain the possibility that the type (or representation) of the result
may depend on the specific values of the arguments? I am arguing for the
latter.
In other words, I deny that the inexactness contagion used for + and * is
appropriate for MAX and MIN. Why is 549755813888.0 the closest we can
come? Only because we have made an arbitrary decision to cast the result
into a representation that reflects the inexactness of the least exact
input, regardless of whether that amount of inexactness in fact had
anything to do with the result computed.
It was not an "arbitrary decision" at all. 549755813888.0 is closest
because we only have 23-bit floating point to represent inexact numbers,
and the answer must be inexact. Its the best we can do. If we return an
exact number we are potentially returning an -INCORRECT- result. We don't
know the answer exactly, so we cannot return an exact number.
Presumably when you say "perhaps 1000 feet" you mean something different
from "perhaps 4 feet", or otherwise you would not bother; you would have a
single inexact number called "perhaps". There is some level of confidence
that leads you to say "perhaps 100" in preference to any other inexact
result. Am I to regard an inexact number as a probability distribution
(whose shape I may know nothing about)? An interval is one kind of
probability distribution. Maybe I am to understand it as more like a
Gaussian, which tails off but is never zero anywhere. Maybe in that case I
agree that (max 4.0 1000) is "perhaps 1000". But then I am not sure I
believe the underlying model. This is not a fair argument, of course,
because I am knocking down my own straw man. But it illustrates the sort
of model for inexact numbers that I seek. I find the "perhaps" model a bit
*too* vague.
WHat can be said about the level of confidence that leads one to
say "perhaps 1000" instead of merely "perhaps"?
--Guy
∂23-Aug-89 1238 jinx@hpesogg.hp.com Just add WITH-VALUES and VALUES.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 12:38:33 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA06929; Wed, 23 Aug 89 15:13:04 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA27595; Wed, 23 Aug 89 12:12:31 pdt
Message-Id: <8908231912.AA27595@sde.hp.com>
Received: by hpesogg; Wed, 23 Aug 89 12:11:50 pdt
Date: Wed, 23 Aug 89 12:11:50 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: jar@zurich.ai.mit.edu
Cc: ramsdell@linus.mitre.org, rrrs-authors@life.ai.mit.edu
In-Reply-To: Jonathan Rees's message of Wed, 23 Aug 89 13:51:53 edt <8908231751.AA00815@zurich.ai.mit.edu>
Subject: Just add WITH-VALUES and VALUES.
Reply-To: jinx%hpesogg@sde.hp.com
As long as I'm babbling, my problem with ACCEPTS? or
PROCEDURE-ACCEPTS? is that there is no inverse for it -- no general
way to construct a procedure that can advertise how many arguments it
would like to accept. In particular, it makes invalid Scheme's
currently useful eta-expansion rule: if x is a procedure, then x can
be replaced by (lambda args (apply x args)) [modulo EQ?]. We could
recover some kind of eta rule if we had some way to associate an
ACCEPTS? "method" with a procedure, e.g. maybe (ACCEPTING proc1 proc2)
would return a procedure p that behaved the same as proc1 except that
(ACCEPTS? p n) would return the value returned by (proc2 n).
(You can do this kind of thing in T, which has a crude analogue of
ACCEPTS?.) Then we would have x equivalent to
(accepting (lambda args (apply x args)) (lambda (n) (accepts? x n))).
I'm not proposing ACCEPTING, and I'm not saying that I would veto any
proposal that has ACCEPTS? in it.
I've been considering adding a similar procedure to MIT Scheme for a
while, but along slightly different lines:
(restrict-arity proc1 proc2) -> proc3
where proc3 has the same arity signature that proc2 has, yet invokes
proc1 instead. It must also be the case that
"for all n s.t. (accepts? proc2 n) -> #t, (accepts? proc1 n) -> #t"
otherwise restrict-arity should error.
The "eta" rule would be obtained by doing
(restrict-arity (lambda args (apply x args)) x)
Unfortunately, due to the lack of an optional argument mechanism in
the standard, it would be hard to "copy" things like WRITE-CHAR, but
hopefully (perhaps I'm being naive) this will be resolved
independently.
MIT Scheme currently has a restricted form of this in the following
(provided for a different reason)
(coerce-to-compiled proc1 n) -> proc2
proc2 expects exactly n arguments.
The original intent for this would be that map, or for-each, or
similar things would do their arguments checking once by using
coerce-to-compiled, and then invoke the resulting procedure directly
without any further arity checks.
∂23-Aug-89 1407 gls@think.com theology; MAX and MIN
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 14:06:44 PDT
Received: from Think.COM (Gateway.Think.COM) by life.ai.mit.edu (4.1/AI-4.10) id AA06580; Wed, 23 Aug 89 14:49:47 EDT
Received: from fafnir.think.com by Think.COM; Wed, 23 Aug 89 14:50:20 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 23 Aug 89 14:35:24 EDT
Received: by verdi.think.com; Wed, 23 Aug 89 14:34:50 EDT
Date: Wed, 23 Aug 89 14:34:50 EDT
From: gls@think.com (Guy Steele)
Message-Id: <8908231834.AA13278@verdi.think.com>
To: will@cs.uoregon.edu
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Tue, 22 Aug 89 18:08:24 PDT <8908230108.AA29492@spencer.cs.uoregon.edu>
Subject: theology; MAX and MIN
Date: Tue, 22 Aug 89 18:08:24 PDT
From: will@cs.uoregon.edu
Guy Steele Jr:
Theologically or politically speaking, under the first view inexact numbers
strive to obey laws acknowledged to be perfect, but to a greater or lesser
degree are each in a state of sin. Under the second view they are all
model citizens, adhering perfectly to their own laws which, however, are
acknowledged not to be ideal but merely the best one can do in this
imperfect and finite world.
In the imperfect world I live in, the supremum implied by the phrase
"the best one can do" is even less likely to exist than in the world of
computer arithmetic.
Touche'. Make that "merely a pretty good thing one can do...".
Theologically speaking, Guy's new proposal has the same problem as his old
proposal: It introduces two new demons to undermine a user's faith in
exact numbers. Only the names have changed: now the demons are called
LARGEST and SMALLEST. The damage done by these two procedures won't be
ameliorated by having exactness-preserving SUP and INF as well. For
simplicity, I say that if MAX and MIN, by whatever names, are going to be
exceptions to the perfect rules of exactness, then let's just acknowledge
them as exceptions and to hell, theologically speaking, with the sinfully
striving exactness-preserving versions.
Hm. Mayhaps my metaphor hath become a petard.
I don't see why faith in the *exact* has been undermined, but only faith
in the *inexact* (which was probably misplaced anyway). I think we all
agree that SUP and MAX/LARGEST would agree on exact inputs. I think that
when you speak of "exactness-preserving" you mean "inexactness-preserving",
and similarly "perfect rules of exactness" => "perfect rules of
inexactness" which is then seen to be a contradiction in terms.
--Guy "I Haven't Had So Much Fun While Trying to Be Serious in Years" Steele
∂23-Aug-89 1407 jinx@hpesogg.hp.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 14:07:44 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA06574; Wed, 23 Aug 89 14:49:33 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA26969; Wed, 23 Aug 89 11:49:12 pdt
Message-Id: <8908231849.AA26969@sde.hp.com>
Received: by hpesogg; Wed, 23 Aug 89 11:48:30 pdt
Date: Wed, 23 Aug 89 11:48:30 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: R. Kent Dybvig's message of Wed, 23 Aug 89 11:27:42 -0500 <8908231627.AA04605@life.ai.mit.edu>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com
Ah, but I can ask (and (pair? x) (pair? (cdr x))), and if this is #t,
then I can be certain that (cddr x) won't error.
Similarly, I can ask
(and (accepts? p 3) (accepts? cons 3))
I don't see the difference.
Your argument seems to be that ACCEPTS? is an ill-defined concept ...
My argument is that "accepts?" is virtually meaningless, since it is
a superficial property of the outermost level of the procedure, and there
is no way to extend it further in. If "accepts?" returns #t, so what?
It is only meaningless if the implementor or the programmer purposely
decide to make it unusable. I listed an additional constraint that
would make ACCEPTS? valid in the cases that I'm concerned about here.
I don't care whether you chose to write all your code differently and
therefore make it unusable in YOUR code. I want to be able to use it
on implementation provided procedures and on MY procedures, which I'll
carefully write so that it is meaningful.
∂23-Aug-89 1418 ramsdell@linus.mitre.org Amended WITH-VALUES and VALUES.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 14:18:08 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA08065; Wed, 23 Aug 89 17:00:38 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA23412; Wed, 23 Aug 89 15:56:23 EDT
Posted-Date: Wed, 23 Aug 89 15:56:18 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA10022; Wed, 23 Aug 89 15:56:19 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908231956.AA10022@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Amended WITH-VALUES and VALUES.
In-Reply-To: Your message of Wed, 23 Aug 89 11:38:15 -0700.
<8908231838.AA26758@sde.hp.com>
Date: Wed, 23 Aug 89 15:56:18 EDT
>> In a compromise everyone gives in a little. I don't see you doing
>> that.
>>
>> The semantics that I want is that extra values are truncated when
>> returned to implicit continuations. As a compromise, I accept strict
>> semantics as long as ACCEPTS? is provided. I'm trying to compromise,
>> you are trying to have me surrender.
>>
>>
As Jqnathan Rees points out, the proposal should explicitly say
something about what the arity of implicit continuations. My
compromise proposal says nothing about that subject because I thought
it would eliminate the chance of reaching an agreement. I have an
opinion on the subject, but I will not propose it in the interest of
getting multiple values into Scheme. Implementations may explore many
alteratives. With the current proposal, implementation may or may not
ignore extra values returned by a procedure. All it requires is that
the number of arguments generated by the first argument of WITH-VALUES
matches the arity of the second argument of WITH-VALUES, and (values
E) returns E. To make the situation about VALUES clear, I added a note
to that section.
I leave unspecified the behavior of the following code:
(list (values 1 2))
John
------------------------------ Amended WITH-VALUES Proposal.
(values obj ...) essential procedure
Returns 0 or more values to a receiving procedure (See with-values).
(values) => returns zero (no) values
(values 1) => returns a single value, 1
(values 1 'a) => returns two values, 1 and the symbol a
Note: When applied to one argument, values simply returns its argument.
(with-values generator receiver) essential procedure
Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with no arguments. It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator' or if 'generator' cannot be called with zero arguments.
(with-values
(lambda ()
(values 1 2))
cons) => (1 . 2)
--------------------------------
∂23-Aug-89 1502 dyb@iuvax.cs.indiana.edu Re: Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 15:02:23 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08639; Wed, 23 Aug 89 17:46:33 EDT
Message-Id: <8908232146.AA08639@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Wed, 23 Aug 89 16:46:34 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: mkatz@sesame.stanford.edu
Subject: Re: Multiple values for R4RS.
Cc: rrrs-authors@life.ai.mit.edu
> If we decide to add "accepts?" to the language, we would have to say
> that an implementation is free to return #t if it cannot determine
> whether or not a given number of arguments is accepted by a given
> procedure. An implementation might even define "accepts?" as:
>
> (lambda (procedure arity) #t)
>
> This may seem to water down the predicate, but it only makes explicit
> that which must already be true.
>
> Please explain in what cases you believe ACCEPTS? is inherently undecidable.
> The above message implies there are such cases, but they are not obvious to me.
It's all in how you define the technical term "accepts". Does it mean
that the procedure won't signal an error if you pass it the given
number of arguments, or is it a superficial property the procedure
derived from the syntax of the lambda expression from which the
procedure was derived? The latter isn't very interesting, since I can
fool it easily (see the examples in prior notes), and the former is
obviously undecidable. If it is the latter, then in R4RS Scheme,
"accepts?" is decidable. However, we would have to state in the report
that "accepts" doesn't really mean what it sounds like it means, since
the procedure may in reaility reject the given number of arguments.
Kent
∂23-Aug-89 1506 @zermatt.lcs.mit.edu:ziggy@HX.LCS.MIT.EDU RE: RECORDs proposal
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 15:06:21 PDT
Received: from ZERMATT.LCS.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA08740; Wed, 23 Aug 89 17:52:17 EDT
Received: from RTS-8.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with SMTP id 284438; 23 Aug 89 17:52:09 EDT
Message-Id: <2828901124-3894493@RTS-8>
Sender: ziggy@rts-8.ai.mit.edu
Date: Wed, 23 Aug 89 17:52:04 EDT
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
To: rrrs-authors%life.ai.mit.edu@zermatt.ai.mit.edu
Subject: RE: RECORDs proposal
Not to detract from the Multiple Values Return debate nor the Numbers polemic
(both of which are very informative), but lest we forget about RECORDs, I have
a couple questions. Forgive me if I missed a discussion, the outcome of which
is reflected in the original proposal, but I am concerned that the current
proposal makes it difficult for me to treat the order of slot-names in a
record as irrelevant. First,
> (RECORD-TYPE-SLOT-NAMES rtd)
>
> Returns a list of the symbols naming the slots in members of the type
> represented by rtd. The returned value is EQUAL? to the slot-names
> argument given in the call to MAKE-RECORD-TYPE that created the type
> represented by rtd.
Why stipulate that this be EQUAL? to the original call? Why does it not
suffice for it to be merely SET-EQUAL? (that is, some permutation of the
original slot-names list)?
Is there something technical you can do with the result as specified that you
would not necessarily be able to do with the result of the looser spec? Note
one possible implementation of the looser spec is to do just what you
specified: use the identity permutation.
Why do I ask? I would like to create a rtd by first sorting the slot-names
argument (e.g., by lexicographical order of the slot-names' print names) and
create an rtd with this sorted slot-names list. This is because I want
slot-names to be order-irrelevant.
To that end, I'm not sure I find RECORD-CONSTRUCTOR particularly useful as it
is. To point:
> (RECORD-CONSTRUCTOR rtd)
>
> Returns a procedure for constructing new members of the type represented by
> rtd. The returned procedure accepts exactly as many arguments as there
> were slot-names in the call to MAKE-RECORD-TYPE that created the type
> represented by rtd; these are used, in order, as the initial values of
> those slots in a new record, which is returned by the constructor
> procedure.
My concern is that the generated constructor operates By Order of Arguments,
what CLtL notes is sometimes called a BOA constructor. What I want is a
construction procedure Wherein (arg) ORder is Considered IRrelevent: a
construction WORCIR (Worker? Rather suggests that it does a little more work
than a mere limbless reptile, no?). For example:
I would rather see a constructor procedure that looks more like:
(DEFINE make-mumble (RECORD-CONSTRUCTOR mumble-rtd))
(make-mumble slot-name val slot-name val...)
It should signal an error if I name a slot not in the slot-names of mumble-rtd
It could be an error if I fail to name a slot that IS in the slot-names of
mumble-rtd.
Again, the point being that I want the order of slot names to be irrelevant.
To do otherwise would be to give me something not much more useful than
VECTORs. Thus when I make an instance of some record type, I don't want to
have to order the initial values to match the irrelevantly ordered slot-names.
I would rather provide slot-name/value duples.
For the case where you don't mind observing the irrelevant defined order
(e.g., to avoid naming all the slots) you could use a RIGID-RECORD-CONSTRUCTOR
which could function as you specified. (RECORD-BOA-CONSTRUCTOR)
Or better yet, I would like a syntax like:
(make-mumble ((slot-name val)(slot-name val)...))
since I imagine object instantiation to be essentially a binding and packaging
operation [make a bunch of bindings, package them into a RECORD, and return
the RECORD], but I wouldn't dare propose that lest you all banish me to the
mythical macro library or condemn me of perpetuating syntax.
Fnord. Not to mention defaulting. Fnord.
~Ziggy
∂23-Aug-89 1513 jinx@hpesogg.hp.com Amended WITH-VALUES and VALUES.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 15:13:12 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA08791; Wed, 23 Aug 89 17:56:30 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA01098; Wed, 23 Aug 89 14:32:48 pdt
Message-Id: <8908232132.AA01098@sde.hp.com>
Received: by hpesogg; Wed, 23 Aug 89 14:32:06 pdt
Date: Wed, 23 Aug 89 14:32:06 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Wed, 23 Aug 89 15:56:18 EDT <8908231956.AA10022@huxley.mitre.org>
Subject: Amended WITH-VALUES and VALUES.
Reply-To: jinx%hpesogg@sde.hp.com
As Jqnathan Rees points out, the proposal should explicitly say
something about what the arity of implicit continuations. My
compromise proposal says nothing about that subject because I thought
it would eliminate the chance of reaching an agreement. I have an
opinion on the subject, but I will not propose it in the interest of
getting multiple values into Scheme. Implementations may explore many
alteratives. With the current proposal, implementation may or may not
ignore extra values returned by a procedure. All it requires is that
the number of arguments generated by the first argument of WITH-VALUES
matches the arity of the second argument of WITH-VALUES, and (values
E) returns E. To make the situation about VALUES clear, I added a note
to that section.
I will accept the proposal if it leaves the arity of implicit
continuations unspecified, and it is explicitely stated.
∂23-Aug-89 1516 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 15:15:52 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA08792; Wed, 23 Aug 89 17:56:38 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa10082;
21 Aug 89 12:22 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Aug 89 12:21:41 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09778;
21 Aug 89 11:54 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01440; Mon, 21 Aug 89 11:54:38 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Mon, 21 Aug 89 11:51:20 edt
Received: from fafnir.think.com by Think.COM; Mon, 21 Aug 89 11:53:56 EDT
Received: from verdi.think.com by fafnir.think.com; Mon, 21 Aug 89 11:51:20 EDT
Received: by verdi.think.com; Mon, 21 Aug 89 11:51:09 EDT
Date: Mon, 21 Aug 89 11:51:09 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8908211551.AA29546@verdi.think.com>
To: jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk
Cc: gls@think.com, cph@zurich.ai.mit.edu, Alan@reagan.ai.mit.edu,
KMP@stony-brook.scrc.symbolics.com, RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Jeff Dalton's message of Sun, 30 Jul 89 17:36:25 BST <11536.8907301636@subnode.aiai.ed.ac.uk>
Subject: INF/SUP/MIN/MAX
Date: Sun, 30 Jul 89 17:36:25 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk>
>From: Guy Steele <gls@think.com>
> Date: Wed, 26 Jul 89 15:49:33 edt
> From: cph@zurich.ai.mit.edu (Chris Hanson)
>
> [quotes Steele's arguments about Quux-head pennies, etc.]
> I don't buy these arguments: many of them have to do with side
> effects, and since when are there any side effects on numbers? So
> they don't apply.
>
> Granted. "Plus ca change, plus c'est la meme chose", as Sussman and I
> quoted in "The Art of the Interpreter". The more things change, the more
> they remain the same; that is, the notion of object identity may be linked
> to the notion of side effect. And yet, if numbers are not subject to
> side effects, in what sense can we say that 1 = 1, or that 1 /= 2 ?
I think this observation of numeric identity shows that identity can
be linked to side-effects, but also that identity doesn't require this
link. Indeed, I don't find the argument that there's some sort of
implicit potential side-effect involved in asking 1 = 1 very
convincing.
How is it, then, that 1 /= 2? What is there that makes them different?
How is it that "+" can distinguish between them? I find it very
unsatisfying to say of "+" merely that it is primitive, it does it
because that's what it does, and I should stop asking so many silly
questions. The same is true, by the way, of symbols: how is it that
"FOO" is distinguishable from "BAR"?
> I think that when we say 1 = 1, we are temporarily entertaining the
> possibility that the two instances of "1" represent *different* things,
> precisely so that we may then make the assertion that they are the same
> after all.
When I say "Nixon is the author of Six Crises", do this mean I'm
temporarily entertaining the possibliity that someone else wrote it?
Well, perhaps I'm at least entertaining the possibility that the
person I'm speaking to thinks so.
Exactly so.
But what if I say just "Nixon is
Nixon"? It may seem that I must have some possibility in mind that I
am trying to deny. But I don't think it's clear what this possibility
is unless I say something more. For example, I might say: "The person
you call 'Nixon' is the same person I know as 'Nixon', the author of
Six Crises, etc., and not two different people as we had once
supposed."
Again, exactly so. See below.
But it's hard to see how there could be this kind of
confusion about "'1' as defined by Scheme".
Only because "1" is a little more famous than Nixon; it's a matter of
degree rather than principle.
Indeed, it seems to me
that once we agree about what "Nixon" refers to, we can say "Nixon is
Nixon" without necessarily entertaining any possibility that Nixon
isn't Nixon.
So I don't think it's straightforward to conclude that when we
say 1 = 1, etc.
> If one of the 1's were not 1 after all, then things would be
> different, including the truth of the equality. This subjunctive
> hypothesis amounts to a side effect, for we are considering, hypothetically
> and however evanescently, a world altered from our own (whether by SETQ
> or by adding an entry to the head of an a-list).
But is every difference the result of a side-effect? Perhaps we're
just entertaining the possibility that "=" doesn't mean what we
thought it meant or that tokens like "1" refer to something different
each time.
The latter is a possibility, however temporarily it is entertained or
however trivially resolved.
∂23-Aug-89 1519 dyb@iuvax.cs.indiana.edu Re: Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 15:19:48 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08887; Wed, 23 Aug 89 18:04:38 EDT
Message-Id: <8908232204.AA08887@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Wed, 23 Aug 89 16:33:43 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: gls@think.com
Subject: Re: Multiple values for R4RS.
Cc: rrrs-authors@life.ai.mit.edu
> You could always walk down the machine language code, trying to figure
> out which registers or stack slots it is touching in order to fetch arguments.
> (This is not a claim of good engineering, just an existence proof.)
> --Guy
Are you assuming that there are explicit references to the registers or
stack slots holding the values? There may in fact be no such
references. Perhaps the code performs some sort of computation to
derive an index into the stack holding the argument and the value of
that computation cannot be determined. Or perhaps the code does not
touch one or more of its arguments explicitly, but leaves them in place
as arguments to another procedure that it calls.
Kent
∂23-Aug-89 1718 dyb@iuvax.cs.indiana.edu Re: multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 17:17:56 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08282; Wed, 23 Aug 89 17:14:45 EDT
Message-Id: <8908232114.AA08282@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Wed, 23 Aug 89 16:15:20 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: rrrs-authors@life.ai.mit.edu
Subject: Re: multiple values
> Note that I'm not asking for a requirement that "(values e)" be
> distinct from "e", only that we not require that "(values e)" be
> the same as "e". So it doesn't rule out an implementation that
> automatically truncates multiple values.
>
> I must be missing something. How does the requirement that "(values e)" and
> "e" be the same rule out an implementation the automatically truncates?
It doesn't! However, among those who want to be allowed to automatically
trucate multiple values, there seems to be an impression that "(values e)"
must be the same as "e" in order for them to to do so. I was merely
pointing out that allowing "(values e)" and "e" to be different does not
preclude their implementations from treating them the same and hence does
not preclude them from implementing automatic truncation.
∂23-Aug-89 1759 halstead@crl.dec.com
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 17:59:05 PDT
Received: from decwrl.dec.com by life.ai.mit.edu (4.1/AI-4.10) id AA10304; Wed, 23 Aug 89 20:42:28 EDT
Received: by decwrl.dec.com; id AA05392; Wed, 23 Aug 89 12:21:43 -0700
Date: Wed, 23 Aug 89 12:21:43 -0700
From: halstead@crl.dec.com
Message-Id: <8908231921.AA05392@decwrl.dec.com>
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
id AA10352; Wed, 23 Aug 89 15:20:38 EDT
Apparently-To: <rhh@lcs.mit.edu>
Apparently-To: <rrrs-authors@life.ai.mit.edu>
Cc: halstead@crl.dec.com, rhh@lcs.mit.edu
Subject: multiple return values -- APPLY-OPTIONAL, a modest proposal
Date: Wed, 23 Aug 89 15:18:27 EDT
From: halstead@crl.dec.com
Here's a fresh look at the problem. It strikes me as kind of way-out,
but maybe not too way-out for serious consideration.
We are concerned with having continuations that may accept multiple
arguments (or no arguments!) and having some way to return to a
continuation the number of arguments that it wants. In the simple
case (no ACCEPTS?, exact arity match required), we can write VALUES
as a procedure
(define (values . vals)
(call/cc
(lambda (k) (apply k vals))))
Yes? (The above is intended to be non-controversial.)
The problem arises when we want to add flexibility to the interface
between VALUES and the continuation, e.g. to implement the Common Lisp
"feature" that allows excess values to be discarded if they are not
wanted by the continuation. This is the motivation for having ACCEPTS?.
Let's step back and consider another case where Scheme already allows
for flexibility in the number of arguments passed. We can already
write a procedure like (lambda (a b . rest) ...) that requires 2 or more
arguments, so the callee can express a willingness to be flexible in
the number of arguments passed, within some limits. The proposal to
include ACCEPTS? is motivated by a desire to allow the *caller* some
similar flexibility, by letting it effectively negotiate with the callee
to settle on a number of arguments that the callee will be happy with.
The problem with that, as Kent points out, is that the negotiation is
only skin-deep, and can't take into account restrictions built into
the callee's definition, e.g., in
(lambda (a b . rest)
(if (> (length rest) 2)
(error ...)
(let ((c (car rest))
(d (cadr rest)))
.... c .... d ....)))
where the procedure really only "accepts" either 2, 3, or 4 arguments.
Can we solve this problem by pushing it down a level? Here's a 3/4-baked
proposal to do just that: introduce a new procedure APPLY-OPTIONAL that
is used as (APPLY-OPTIONAL f a1 a2 ... an optional-args). If f cannot
accept at least n arguments, then this "is an" ("signals an"?) error.
If f requires at least m>=n arguments, then m-n additional arguments
are taken off the list of optional-args. When f looks like it can
accept an unbounded number of arguments, I think you have to pass all of
optional-args. (Perhaps this is the Achilles heel of the proposal.)
Now we can write a VALUES that operates as in Common Lisp like this:
(define (values . vals)
(call/cc
(lambda (k)
(apply-optional k vals))))
(or you can vary it to suit your tastes regarding special treatment of
supplying 0 arguments to VALUES, etc.).
I like this idea because it makes the call interface more symmetrical
regarding optional arguments: if the callee gets to specify flexibility
in accepting calls from different kinds of callers, why shouldn't the
callers be able to specify similar flexibility in the callees they will
deal with? I also think this proposal avoids the problems that Kent
has criticized ACCEPTS? for: in this proposal, the code inside the
procedure gets to decide whether it will accept a given set of arguments
-- or it can pass the buck on that decision -- without needing to encode
its criteria in a form that ACCEPTS? can decipher. On the other hand,
some cans of worms are opened: my 2-, 3-, or 4-argument procedure above
would reject a call like (APPLY-OPTIONAL F 1 2 3 '(4 5 6)) even though
there is a way to satisfy F's requirements. To fix this, we need to give
a procedure some hooks so it can tell which of its arguments were optionally
supplied. Urk!
Comments? -Bert Halstead
∂23-Aug-89 1954 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com MIN and MAX (long message)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 19:53:59 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA10974; Wed, 23 Aug 89 22:31:43 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11410;
21 Aug 89 14:19 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Aug 89 14:19:48 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa11318;
21 Aug 89 14:12 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02850; Mon, 21 Aug 89 14:12:13 EDT
Received: from life.ai.mit.edu (life.ai.mit.edu) by zurich.ai.mit.edu; Mon, 21 Aug 89 14:08:57 edt
Received: from Think.COM (Gateway.Think.COM) by life.ai.mit.edu (4.1/AI-4.10) id AA02847; Mon, 21 Aug 89 14:12:06 EDT
Received: from fafnir.think.com by Think.COM; Mon, 21 Aug 89 14:09:47 EDT
Received: from verdi.think.com by fafnir.think.com; Mon, 21 Aug 89 14:07:21 EDT
Received: by verdi.think.com; Mon, 21 Aug 89 14:07:11 EDT
Date: Mon, 21 Aug 89 14:07:11 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8908211807.AA01875@verdi.think.com>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Mon, 7 Aug 89 16:02:42 PDT <8908072302.AA04327@spencer.cs.uoregon.edu>
Subject: MIN and MAX (long message)
Date: Mon, 7 Aug 89 16:02:42 PDT
From: will@cs.uoregon.edu
Guy Steele Jr:
...every C weenie has the formula
#define max(x,y) ((x) > (y)) ? (x) : (y)
engraved in his little weenie brain. See? MAX really is a conditional.
I'm not much of a C weenie, and I don't have a description of the
proposed (or actual?) ANSI standard, but I think I know enough C to
suspect that Guy didn't mean for us Scheme weenies to take this seriously.
When examined more closely, Guy's example shows that C weenies think more
like me than like Guy. (This doesn't surprise me, unfortunately.)
C is a statically typed language, with very little polymorphism, that
regards ints and floats as different types. (I'm going to speak as
though all the different integer types were collapsed into one type, and
all the different float types into one type.) The two alternatives of
a conditional expression must have the same type, or else be convertible
to the same type using C's conversion rules. If you define max as Guy
suggested and then write max(2.5, 1000) as an expression, then the result
of that expression will be a float (1000.0), not an int.
If you write max(2.5, 1000) in a context that expects an int, then the
floating point 1000.0 will be converted back into an int (1000). (It
isn't wise to regard that conversion as part of the expression's
semantics, because you would then have to believe that max(2, 1000.5)
also evaluates to an int.) Hence max(2.5, 1000) in an int context is
really the equivalent of (INEXACT->EXACT (TRUNCATE (MAX 2.5 1000))) in
Scheme.
So if MAX really is a conditional in C, then (MAX 2.5 1000) ==> 1000.0
is consistent with MAX being a conditional. It seems that Guy's example
actually supports the R3.95RS semantics he was arguing against.
But my point of view is that the MAX operation per se, like other C
operators is *not* polymorphic. They operate only on two ints or
two floats. The type mechanism enforces this requirement by inserting
coercions; the point is that these coercions are outside the control
of the implementation of the operation itself, and therefore not
properly a part of them. In exactly the same way that max(2.5, 1000)
in an int context ends up having a coercion inserted, so the coercion
that converts 1000 to a float is artificially inserted.
∂23-Aug-89 2120 @mc.lcs.mit.edu,@life.ai.mit.edu:bawden.pa@xerox.com Programmer-defined data types
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 21:20:30 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA12551; Thu, 24 Aug 89 00:04:52 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11727;
21 Aug 89 14:45 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Aug 89 14:44:58 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa11697;
21 Aug 89 14:42 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03287; Mon, 21 Aug 89 14:42:53 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Mon, 21 Aug 89 14:39:20 edt
Received: from Semillon.ms by ArpaGateway.ms ; 21 AUG 89 11:36:45 PDT
Date: Mon, 21 Aug 89 11:34 PDT
From: bawden.pa@xerox.com
Subject: Programmer-defined data types
To: Pavel.pa@xerox.com
Cc: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: <890818-183407-4872@Xerox>
Message-Id: <19890821183403.7.ALAN@ROCKY.parc.xerox.com>
Line-Fold: no
Date: Fri, 18 Aug 89 18:36:26 PDT
From: Pavel.pa@Xerox.COM
(RECORD-CONSTRUCTOR rtd)
Returns a procedure for constructing new members of the type represented by
rtd. The returned procedure accepts exactly as many arguments as there
were slot-names in the call to MAKE-RECORD-TYPE that created the type
represented by rtd; these are used, in order, as the initial values of
those slots in a new record, which is returned by the constructor
procedure.
I prefer the alternative that someone (RRJ?) made the last time we
discussed this:
(RECORD-CONSTRUCTOR rtd slot-names)
Where slot-names is a subset of the slot-names given to MAKE-RECORD-TYPE.
The returned procedure accepts exactly as many arguments as there are
slot-names. It creates a new record and initializes the specified slots.
Not only is this more flexible, but it is more readable. If you go looking
for the definition of MAKE-SPACESHIP and you find
(DEFINE MAKE-SPACESHIP (RECORD-CONSTRUCTOR SPACESHIP-RTD))
chances are your next move is to go looking for the definition of
SPACESHIP-RTD so you can figure out what the arguments to MAKE-SPACESHIP
are. Ugh. On the other hand, if you find
(DEFINE MAKE-SPACESHIP
(RECORD-CONSTRUCTOR SPACESHIP-RTD '(NAME CAPTAIN)))
chances are good that you won't need to look any further.
=====================
Notes on the proposal
=====================
-- The type-name argument to MAKE-RECORD-TYPE is constrained to be a string
in order to allow experimentation with interesting semantics for other
kinds of values there. One possibility raised in the discussion in 1988
was some kind of a ``handler'' procedure, as in T objects.
Even if someday you can pass a ``handler'' to MAKE-RECORD-TYPE, mightn't
you -also- want to pass a type-name? I don't see how the two are
exclusive.
-- A case can be made that constructor procedures should take no arguments
and leave all slots in new records uninitialized. There appear to be
advantages to both points of view.
I'm not sure I understand why anyone would advocate this. Would such
people be made happy if
(RECORD-CONSTRUCTOR SPACESHIP-RTD '())
returns such a constructor? Or do such people think that the user should
be forced to use side-effects to initialize records?
-- ... The consensus of those I've spoken to concerning EQUAL? is that
it should be equivalent to EQV? on records, instead of treating them as
it treats vectors, pairs, and strings....
My personal preference: I have never wanted to compare records by
comparing their contents slot-by-slot. I -have- wanted to compare two
lists of records to see if they contain the same (EQ) records. The latter
application is at least slow and can also be dangerous if EQUAL? descends
records (the records may be part of a circular structure). That is why I
feel EQUAL? should not descend records.
∂23-Aug-89 2230 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com Programmer-defined data types
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 22:29:44 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA13061; Thu, 24 Aug 89 01:03:13 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa15594;
21 Aug 89 20:03 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Aug 89 20:03:47 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa15473;
21 Aug 89 19:54 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06715; Mon, 21 Aug 89 19:54:51 EDT
Received: from life.ai.mit.edu (life.ai.mit.edu) by zurich.ai.mit.edu; Mon, 21 Aug 89 19:51:36 edt
Received: from RELAY.CS.NET by life.ai.mit.edu (4.1/AI-4.10) id AA06690; Mon, 21 Aug 89 19:53:24 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa10653; 21 Aug 89 18:45 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA07835; Mon, 21 Aug 89 15:47:53 PDT
Received: by tekirl.labs.tek.com (5.51/7.1)
id AA12356; Mon, 21 Aug 89 15:45:47 PDT
Received: by tekchips.LABS.TEK.COM (5.51/6.24)
id AA18203; Mon, 21 Aug 89 15:48:14 PDT
Date: Mon, 21 Aug 89 15:48:14 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Message-Id: <8908212248.AA18203@tekchips.LABS.TEK.COM>
To: RRRS-Authors@zurich.ai.mit.edu
Cc: Pavel.pa@xerox.com
Subject: Programmer-defined data types
I support Pavel's proposal for records.
I would prefer that each abstraction-breaking procedure is identified as
such in its description. I prefer the term "field" to "slot."
-- Should there be a RECORD-COPIER procedure? Some folks would like to
have one for performance and convenience..
I can think of many operations generic to records. I don't think
copying deserves to be a special case.
-Norman
∂24-Aug-89 0210 @mc.lcs.mit.edu:bawden.pa@xerox.com Numbers and Pork Rinds
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Aug 89 02:10:51 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00766; Thu, 24 Aug 89 05:02:00 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22028;
24 Aug 89 0:31 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Aug 89 00:21:49 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa19440; 23 Aug 89 21:18 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 23 AUG 89 17:36:27 PDT
Date: Wed, 23 Aug 89 17:33 PDT
From: bawden.pa@xerox.com
Subject: Numbers and Pork Rinds
To: gls@think.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8908231825.AA13164@verdi.think.com>
Message-Id: <19890824003336.4.ALAN@ROCKY.parc.xerox.com>
Line-Fold: no
Date: Wed, 23 Aug 89 14:25:31 EDT
From: gls@Think.COM (Guy Steele)
Here is where the cart may be before the horse. I'll let you inspect the
*types* of the arguments up front in any case. Are you then deciding a
priori to use floating-point to represent the result only on the basis of
the argument types, without regard to the values involved? Or do you
entertain the possibility that the type (or representation) of the result
may depend on the specific values of the arguments? I am arguing for the
latter.
Of course the type of the answer may depend on more than the datatype of
argument. Consider the case of `*'. In general (* <inexact> <exact>)
yields an inexact number. But in the case of (* <inexact> 0) you may
return an exact 0. If your implementation used interval arithmetic, then
(MAX <inexact> <exact>) may well be able to return an exact number, given
the bounds contained in the inexact argument:
(MAX #<Interval 3 through 5> 10) ==> 10
(MAX #<Interval 9 through 11> 10) ==> #<Interval 10 through 11>
BUT IN THE CASE WHERE FLOATING POINT IS USED I do not believe there is any
case where an exact answer may be returned if one of the arguments is
inexact.
Presumably when you say "perhaps 1000 feet" you mean something different
from "perhaps 4 feet", or otherwise you would not bother; you would have a
single inexact number called "perhaps". There is some level of confidence
that leads you to say "perhaps 100" in preference to any other inexact
result. Am I to regard an inexact number as a probability distribution
(whose shape I may know nothing about)?
No, an inexact number is not necessarily a probability distribution
(although that might be an interesting representation to explore). I can't
tell you what it is in general. Sorry. We aren't specifying the behavior
of inexact numbers here.
All I care about is that MAX not return an exact answer unless the
implementation really -knows- that that exact number is the correct answer.
That's all I care about. Read my lips.
∂24-Aug-89 0323 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #186
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Aug 89 03:23:49 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00947; Thu, 24 Aug 89 05:43:56 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24786;
24 Aug 89 3:24 EDT
Date: 24 AUG 89 00:14:20 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Subject: Scheme Digest #186
To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id: <8908240324.aa24786@mintaka.lcs.mit.edu>
Scheme Digest #186 24 AUG 89 00:14:20 EDT
Today's Topics:
Problem with XScheme 0.16
----------------------------------------------------------------------
Date: 23 Aug 89 21:12:18 GMT
From: Brian of ASTD-CP <brian@topaz.rutgers.edu>
Subject: Problem with XScheme 0.16
Message-Id: <1639@jato.Jpl.Nasa.Gov>
I have been using XScheme 0.16 for about 6 months, now, and find it
to be quite useful. I have been running it on Silicon Graphics
workstations, specifically, the IRIS 3130 and the Personal Iris.
In all the time I have been using the program, I have found only
one non-trivial bug. The author of XScheme, David Betz, deserves
considerable praise for the robustness and performance of XScheme.
Having been inside the source, I have found it to be some of the
cleanest, easiest-to-understand C code I have ever seen. However,
I have determined that I will be unable to debug the problem
without spending several days instrumenting the code. I have
written to David to ask his help, and I thought I might query the
network, too, in case someone out there has already solved the
problem and can save me those few days' work.
The following operations cause a "segmentation violation" on the
Personal Iris
XScheme version 0.16 (with IRIS graphics primitives)
> (save "foo")
#t
> (restore "foo")
[ returning to the top level ]
> (* 3 4)
Segmentation violation (core dumped)
A traceback shows
putnumber / xsprint / xlprint / xwrite / xlapply / xlexecute / main
with the program dying at line 278 in xsprint.c at the statement
LVAL fmt = getvalue(s_fixfmt) ;
The following sequence may also be instructive.
XScheme version 0.16 (with IRIS graphics primitives)
> (save "foo")
#t
> (restore "foo")
[ returning to top level ]
> (save "bar")
#t
> (exit)
UNIX% cmp foo bar
foo bar differ: char 94, line 1
My intuition tells me that the two files should be identical. To
give some context, the Personal Iris is a MIPS processor, running
Silicon Graphics' own UNIX, part system V, part BSD 4.2. In this
test, I am running XScheme as "clean" as possible, without the file
"xscheme.ini", without syntax extensions, etc. Bringing up XScheme
with my usual environment, which contains hundreds of graphics
definitions, R. K. Dybvig's syntax extender, etc., etc., causes
XScheme to crash deep in the restore statement itself. I have not
modified the XScheme core, that is, David Betz's code. I have only
added graphics routines in new files.
My hunch is that information about the contents of memory is either
not getting saved correctly or not getting restored correctly, and
the next step seems to be to collect information about the save and
restore processes. I spent a couple of hours desk-checking the
code in xsimage.c for "xlsave" and "xlrestore". There is nothing
obviously wrong. I decided that my next step would be to create
versions of save and restore that deal with a printable format, so
I could see what is being saved and restored, and I prepared myself
to build a memory analyzer that would print out the contents of
memory so I could verify that restore is doing the right thing. I'd
like to avoid doing all this if someone out there has already fixed
the problem.
By the way, save and restore are necessary in my graphics work
because I need to be able to load complex graphics models very
quickly, in compiled form, without going through recompilation.
Please e-mail or phone me if you have a solution, and thanks in
advance.
. . . Dr. Brian Beckman . . . . . . . . . . . . 4800 Oak Grove Drive . . . . .
. . . Computer Graphics Laboratory. . . . . . . Pasadena, CA 91109 . . . . . .
. . . MS 510-202, Jet Propulsion Laboratory . . (818) 397-9207 . . . . . . . .
. . . California Institute of Technology. . . . brian@topaz.jpl.nasa.gov . . .
------------------------------
End of Scheme Digest
********************
∂24-Aug-89 0428 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #182
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Aug 89 04:28:03 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01348; Thu, 24 Aug 89 06:26:03 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09295;
19 Aug 89 0:42 EDT
Date: 19 AUG 89 00:09:54 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Subject: Scheme Digest #182
To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id: <8908190042.aa09295@mintaka.lcs.mit.edu>
Scheme Digest #182 19 AUG 89 00:09:54 EDT
Today's Topics:
Cscheme posting
----------------------------------------------------------------------
Date: 18 Aug 89 17:34:34 GMT
From: Bob Sutterfield <tinman.cis.ohio-state.edu!bob@ohio-state.arpa>
Subject: Re: Cscheme posting
Message-Id: <BOB.89Aug18133434@tinman.cis.ohio-state.edu>
In article <8907241613.AA01903@zurich.ai.mit.edu> cph@ZURICH.AI.MIT.EDU (Chris Hanson) writes:
In article <6592@cognos.UUCP> rossj@cognos.UUCP (Ross Judson) writes:
A month or two ago I read that somebody planned on posting the
most recent version... Unfortunately, I am unable to ftp... So
posting is the only way I'll see it.
There is no chance that anyone will post CScheme -- the current
distribution is 6 megabytes in size, over 2 megabytes when
compressed. You will have to find someone who has a copy and can
get it to you.
I have updated the C Scheme on osu-cis to 7.0, available for anonymous
UUCP. Though it's pretty huge, we now have a TB+ and a V.32 that
should help keep your costs down when you call for it. Write to
osu-cis!uucp (same as uucp@cis.ohio-state.edu) for instructions if you
don't already know how to get the current set.
(BTW, it's not at all safe to say that "there's no chance" of
something stupid happening in the Usenet - someone, somewhere, will
gladly prove you wrong. :-)
------------------------------
End of Scheme Digest
********************
∂24-Aug-89 0504 ramsdell@linus.mitre.org Revised WITH-VALUES and VALUES (I think we are near agreement!)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Aug 89 05:03:54 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02200; Thu, 24 Aug 89 07:44:51 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA04381; Thu, 24 Aug 89 07:39:23 EDT
Posted-Date: Thu, 24 Aug 89 07:39:19 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA10826; Thu, 24 Aug 89 07:39:21 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908241139.AA10826@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Revised WITH-VALUES and VALUES (I think we are near agreement!)
Date: Thu, 24 Aug 89 07:39:19 EDT
>> From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
>>...
>> I will accept the proposal if it leaves the arity of implicit
>> continuations unspecified, and it is explicitely stated.
Here is my rewrite. I interpret your request as follows. If the
arity of implicit continuations is unspecified we plan to allow both
implementations using implicit continuations which require exactly one
value and those using continuations which accept one or more values.
In particular, if the arity of implicit continuations are unspecified,
some implementations may signal an error when given more than one
value. As I understand R4RS lingo, I must use the phrase "an error"
to describe situations in which some implementations can signal an
error, and others do not have to. The phrase "unspecified" means that
no error can be reported which would imply that the arity of implicit
continuations are specified. Please bless this or suggest an
alternate wording.
John
---------------
(values obj ...) essential procedure
Returns 0 or more values to a receiving procedure (See with-values).
(values) => returns zero (no) values
(values 1) => returns a single value, 1
(values 1 'a) => returns two values, 1 and the symbol a
Values applied to one argument simply returns its argument. Returning
more than one value or zero values to something other than a receiving
procedure is an error.
(with-values generator receiver) essential procedure
Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with no arguments. It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator' or if 'generator' cannot be called with zero arguments.
(with-values
(lambda ()
(values 1 2))
cons) => (1 . 2)
--------------------------------
∂24-Aug-89 0600 @mc.lcs.mit.edu:bawden.pa@xerox.com Numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Aug 89 06:00:02 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02707; Thu, 24 Aug 89 08:49:05 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16115;
21 Aug 89 20:38 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Aug 89 20:38:08 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa16079; 21 Aug 89 20:35 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 21 AUG 89 17:34:35 PDT
Date: Mon, 21 Aug 89 17:24 PDT
From: bawden.pa@xerox.com
Subject: Numbers
To: gls@think.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8908211534.AA29201@verdi.think.com>
Message-Id: <19890822002405.2.ALAN@ROCKY.parc.xerox.com>
Line-Fold: no
Date: Mon, 21 Aug 89 11:34:37 EDT
From: Guy Steele <gls@think.com>
I'm back from an exhausting, and therefore very restful, vacation.
Back into the fray!
I was wondering why I hadn't heard from you. I couldn't imagine that you
had given up the argument!
Here is a new proposal. Given a set of points within a partial order,
there are two interesting kinds of "max"-like operation. One is to find
some point (not necessarily within the set) that is >= all points in the
given set; this is SUP....
Another is to find some point in the set such that no point in the set is >
that point....
But the version of MAX I am advocating isn't either of these! I would
allow:
(max 1.0 549755813889) ==> 549755813888.0
Where presumably (< 549755813888.0 549755813889) is true. Thus MAX can
return an object that, according to `<', is smaller than one of the
arguments.
Now I'm sure that about half of you are shouting at your terminal about how
I couldn't -possibly- mean that, but I do. Understand me once and for all:
INEXACT NUMBERS ARE NOT NUMBERS
INEXACT NUMBERS ARE NOT NUMBERS
INEXACT NUMBERS ARE NOT NUMBERS
They do not obey the rules followed by numbers, because they cannot.
Inexact numbers only represent our -approximate- -knowledge- about numbers.
In
(max 1.0 549755813889) ==> 549755813888.0
we strongly suspect that the first number is 1, but we don't know for sure.
Thus we strongly suspect that the answer is 549755813889, but again we
don't know for sure (the first number could have actually been
549755813890). Since we don't know the answer for sure, we must return an
inexact representation of our best guess. 549755813888.0 is the closest we
can come. (The next larger might be 549755879424.0, assuming 23 bits of
floating point precision, which is not very close at all.)
Indeed, we could -specify- that MAX always ``round up'' in the inexact case
so that the result always appears greater (accroding to `<') than any of
the arguments. This would be similar to specifying that `<' must always
behave transitively. It would be a feeble attempt on our part to paper
over the ugly fact that -in- -general-, inexact numbers do not obey the
axioms of arithmetic.
∂24-Aug-89 0629 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #183
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Aug 89 06:29:15 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02557; Thu, 24 Aug 89 08:42:13 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22139;
20 Aug 89 0:04 EDT
Date: 20 AUG 89 00:02:31 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Subject: Scheme Digest #183
To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id: <8908200004.aa22139@mintaka.lcs.mit.edu>
Scheme Digest #183 20 AUG 89 00:02:31 EDT
Today's Topics:
Don't Read This If You Get Tired Easily At Whiney Requests
----------------------------------------------------------------------
Date: 19 Aug 89 02:58:33 GMT
From: "Jack J. Woehr" <cs.utexas.edu!sun-barr!apple!well!jax@ohio-state.arpa>
Subject: Don't Read This If You Get Tired Easily At Whiney Requests
Message-Id: <13213@well.UUCP>
blah, blah, blah, latest version on Amiga? blah blah blah ...
------------------------------
End of Scheme Digest
********************
∂24-Aug-89 1002 cph@zurich.ai.mit.edu Revised WITH-VALUES and VALUES (I think we are near agreement!)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Aug 89 10:02:47 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA04241; Thu, 24 Aug 89 12:13:02 EDT
Received: from localhost by zurich.ai.mit.edu; Thu, 24 Aug 89 12:09:48 edt
Date: Thu, 24 Aug 89 12:09:48 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8908241609.AA12852@zurich.ai.mit.edu>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: ramsdell@linus.mitre.org's message of Thu, 24 Aug 89 07:39:19 EDT <8908241139.AA10826@huxley.mitre.org>
Subject: Revised WITH-VALUES and VALUES (I think we are near agreement!)
From: ramsdell@linus.mitre.org
Date: Thu, 24 Aug 89 07:39:19 EDT
(values obj ...) essential procedure
Returns 0 or more values to a receiving procedure (See with-values).
(values) => returns zero (no) values
(values 1) => returns a single value, 1
(values 1 'a) => returns two values, 1 and the symbol a
Values applied to one argument simply returns its argument. Returning
more than one value or zero values to something other than a receiving
procedure is an error.
May I suggest rewording the last sentence as follows? This eliminates
a small ambiguity.
"Returning zero values or more than one value to something other than
a receiving procedure is an error."
∂24-Aug-89 1009 gls@think.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Aug 89 10:09:43 PDT
Received: from Think.COM (Gateway.Think.COM) by life.ai.mit.edu (4.1/AI-4.10) id AA03436; Thu, 24 Aug 89 10:26:25 EDT
Received: from fafnir.think.com by Think.COM; Thu, 24 Aug 89 10:26:06 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 24 Aug 89 10:23:28 EDT
Received: by verdi.think.com; Thu, 24 Aug 89 10:23:14 EDT
Date: Thu, 24 Aug 89 10:23:14 EDT
From: gls@think.com (Guy Steele)
Message-Id: <8908241423.AA28886@verdi.think.com>
To: dyb@iuvax.cs.indiana.edu
Cc: gls@think.com, rrrs-authors@life.ai.mit.edu
In-Reply-To: R. Kent Dybvig's message of Wed, 23 Aug 89 16:33:43 -0500 <8908232205.AA29152@Think.COM>
Subject: Multiple values for R4RS.
Date: Wed, 23 Aug 89 16:33:43 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
> You could always walk down the machine language code, trying to figure
> out which registers or stack slots it is touching in order to fetch arguments.
> (This is not a claim of good engineering, just an existence proof.)
> --Guy
Are you assuming that there are explicit references to the registers or
stack slots holding the values? There may in fact be no such
references. Perhaps the code performs some sort of computation to
derive an index into the stack holding the argument and the value of
that computation cannot be determined. Or perhaps the code does not
touch one or more of its arguments explicitly, but leaves them in place
as arguments to another procedure that it calls.
Kent
Each implementor presumably will know whether his/her compiler generates
code obeying sufficient constraints that this technique will work.
Don't overlook the possibility of limited abstract simulation of the machine
code. My point is that under *some* circumstances it is not necessary
to encode the arity separately.
--Guy
∂24-Aug-89 1202 ramsdell@linus.mitre.org Re: Revised WITH-VALUES and VALUES (I think we are near agreement!)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Aug 89 12:02:35 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA05575; Thu, 24 Aug 89 14:28:08 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA09690; Thu, 24 Aug 89 14:28:49 EDT
Posted-Date: Thu, 24 Aug 89 14:22:31 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA11476; Thu, 24 Aug 89 14:22:32 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908241822.AA11476@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: Re: Revised WITH-VALUES and VALUES (I think we are near agreement!)
In-Reply-To: Your message of Thu, 24 Aug 89 12:09:48 -0400.
<8908241609.AA12852@zurich.ai.mit.edu>
Date: Thu, 24 Aug 89 14:22:31 EDT
I take Chris's suggestion as a friendly amendment and accept it unless
some one objects.
John
>> From: cph@zurich.ai.mit.edu (Chris Hanson)
...
>> May I suggest rewording the last sentence as follows? This eliminates
>> a small ambiguity.
>>
>> "Returning zero values or more than one value to something other than
>> a receiving procedure is an error."
∂25-Aug-89 0414 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu Programmer-defined data types
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Aug 89 04:14:19 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00985; Fri, 25 Aug 89 05:42:02 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01808;
24 Aug 89 13:46 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Aug 89 13:46:19 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa00637;
24 Aug 89 12:01 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA04169; Thu, 24 Aug 89 11:58:34 EDT
Received: from localhost by zurich.ai.mit.edu; Thu, 24 Aug 89 11:55:21 edt
Date: Thu, 24 Aug 89 11:55:21 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8908241555.AA11386@zurich.ai.mit.edu>
To: bawden.pa@xerox.com
Cc: Pavel.pa@xerox.com, RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: bawden.pa@xerox.com's message of Mon, 21 Aug 89 11:34 PDT <19890821183403.7.ALAN@ROCKY.parc.xerox.com>
Subject: Programmer-defined data types
Date: Mon, 21 Aug 89 11:34 PDT
From: bawden.pa@xerox.com
Line-Fold: no
Date: Fri, 18 Aug 89 18:36:26 PDT
From: Pavel.pa@Xerox.COM
(RECORD-CONSTRUCTOR rtd)
Returns a procedure for constructing new members of the type represented by
rtd. The returned procedure accepts exactly as many arguments as there
were slot-names in the call to MAKE-RECORD-TYPE that created the type
represented by rtd; these are used, in order, as the initial values of
those slots in a new record, which is returned by the constructor
procedure.
I prefer the alternative that someone (RRJ?) made the last time we
discussed this:
(RECORD-CONSTRUCTOR rtd slot-names)
Where slot-names is a subset of the slot-names given to MAKE-RECORD-TYPE.
The returned procedure accepts exactly as many arguments as there are
slot-names. It creates a new record and initializes the specified slots.
I agree with this wholeheartedly. I think this form of the
constructor-constructor is significantly more useful.
-- A case can be made that constructor procedures should take no arguments
and leave all slots in new records uninitialized. There appear to be
advantages to both points of view.
I'm not sure I understand why anyone would advocate this. Would such
people be made happy if
(RECORD-CONSTRUCTOR SPACESHIP-RTD '())
returns such a constructor? Or do such people think that the user should
be forced to use side-effects to initialize records?
If it is the case that there are advantages to both points of view,
then whatever is provided should support both. I think Alan's
suggestion does this.
∂25-Aug-89 1016 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers and Pork Rinds
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Aug 89 10:16:19 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04768; Fri, 25 Aug 89 12:57:30 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02281;
24 Aug 89 14:14 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Aug 89 13:49:58 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa01560;
24 Aug 89 13:30 EDT
Received: from fafnir.think.com by Think.COM; Thu, 24 Aug 89 12:31:35 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 24 Aug 89 12:28:57 EDT
Received: by verdi.think.com; Thu, 24 Aug 89 12:28:42 EDT
Date: Thu, 24 Aug 89 12:28:42 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8908241628.AA00798@verdi.think.com>
To: bawden.pa@xerox.com
Cc: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: bawden.pa@xerox.com's message of Wed, 23 Aug 89 17:33 PDT <19890824003336.4.ALAN@ROCKY.parc.xerox.com>
Subject: Numbers and Pork Rinds
Date: Wed, 23 Aug 89 17:33 PDT
From: bawden.pa@xerox.com
Date: Wed, 23 Aug 89 14:25:31 EDT
From: gls@Think.COM (Guy Steele)
Here is where the cart may be before the horse. I'll let you inspect the
*types* of the arguments up front in any case. Are you then deciding a
priori to use floating-point to represent the result only on the basis of
the argument types, without regard to the values involved? Or do you
entertain the possibility that the type (or representation) of the result
may depend on the specific values of the arguments? I am arguing for the
latter.
Of course the type of the answer may depend on more than the datatype of
argument. Consider the case of `*'. In general (* <inexact> <exact>)
yields an inexact number. But in the case of (* <inexact> 0) you may
return an exact 0. If your implementation used interval arithmetic, then
(MAX <inexact> <exact>) may well be able to return an exact number, given
the bounds contained in the inexact argument:
(MAX #<Interval 3 through 5> 10) ==> 10
(MAX #<Interval 9 through 11> 10) ==> #<Interval 10 through 11>
BUT IN THE CASE WHERE FLOATING POINT IS USED I do not believe there is any
case where an exact answer may be returned if one of the arguments is
inexact.
Very well; we are making progress. You do admit that in some circumstances,
in some implementations, it may make sense for (max 4.0 1000) to return an
exact 1000, say in the case where "4.0" is interpreted by the reader to
mean "the interval from 3.95 to 4.05".
My argument, then, is as follows. Floating-point is indeed so screwed up
that the implementor cannot a priori regard them as intervals or as
anything else interesting, and therefore cannot return an exact result for
the supremum operation. HOWEVER, in some cases the user, knowing the
properties of the floating-point arithmetic, can with his additional
understanding determine that they may be regarded as intervals (or
something close to that) for his purposes. Therefore the user should be
given a choice. LARGEST and SMALLEST may be useful alternatives; *but* I
have also managed to argue that their use is not portable. (On the other
hand, many uses of inexact arithmetic will be nonportable in precisely the
same manner, so to this we should not attach too great a stigma.)
Presumably when you say "perhaps 1000 feet" you mean something different
from "perhaps 4 feet", or otherwise you would not bother; you would have a
single inexact number called "perhaps". There is some level of confidence
that leads you to say "perhaps 100" in preference to any other inexact
result. Am I to regard an inexact number as a probability distribution
(whose shape I may know nothing about)?
No, an inexact number is not necessarily a probability distribution
(although that might be an interesting representation to explore). I can't
tell you what it is in general. Sorry. We aren't specifying the behavior
of inexact numbers here.
I meant "probability distribution" to be not an implementation
representation, but a conceptual model that might cover all representations
in one way or another. But that's a side point; you didn't address my main
question. If inexactness is considered by the Scheme standard merely to be
a scarlet letter indicating that a value is in a state of sin and is
therefore not to be trusted (for inexact arithmetic, while required to
strive for "high quality", has no particular portable requirements), then I
want to know how it is that you can ever think that "perhaps 1000" can ever
be said rather than merely "perhaps"; in other words, without some further
requirements on, or knowledge of, the quality of a particular
implementation, why is it not my duty to regard *every* inexact number as
representing merely "perhaps"?
All I care about is that MAX not return an exact answer unless the
implementation really -knows- that that exact number is the correct answer.
That's all I care about. Read my lips.
Okay. Up to now I had understood you additionally to argue that
the implementation can't ever know that for LARGEST, and therefore
LARGEST is a bogus concept. Now that we have found a circumstance
when the implementation *can* know, we have proved that LARGEST is
not bogus. A separate argument now concerns whether it is useless.
But I think I am about to run out of steam. Alan and I have aired
our views pretty thoroughly, tying up a lot of mailboxes in the process.
Hey, all you out there: does anyone else care? Has anyone's mind been
changed as a result of our discussion?
--Guy
∂25-Aug-89 1054 jinx@hpesogg.hp.com Revised WITH-VALUES and VALUES (I think we are near agreement!)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Aug 89 10:53:53 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA05104; Fri, 25 Aug 89 13:35:25 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA06076; Thu, 24 Aug 89 16:23:31 pdt
Message-Id: <8908242323.AA06076@sde.hp.com>
Received: by hpesogg; Thu, 24 Aug 89 16:22:48 pdt
Date: Thu, 24 Aug 89 16:22:48 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Thu, 24 Aug 89 07:39:19 EDT <8908241139.AA10826@huxley.mitre.org>
Subject: Revised WITH-VALUES and VALUES (I think we are near agreement!)
Reply-To: jinx%hpesogg@sde.hp.com
I must use the phrase "an error"
to describe situations in which some implementations can signal an
error, and others do not have to.
The meaning of "is an error" is that the program is incorrect, but the
implementation may not signal the violation. This goes very much
against the grain of what I want, since it says that the program was
illegal in the first place.
I would rather say that the implementation may report the violation of
an implementation restriction (just like in the numeric section). The
program is not in error, neither is the implementation, there is
purely a mismatch.
∂25-Aug-89 1151 ramsdell@linus.mitre.org Re: Revised WITH-VALUES and VALUES (I think we are near agreement!)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Aug 89 11:51:07 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA05921; Fri, 25 Aug 89 14:32:17 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA28340; Fri, 25 Aug 89 14:32:52 EDT
Posted-Date: Fri, 25 Aug 89 14:26:35 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA14483; Fri, 25 Aug 89 14:26:36 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908251826.AA14483@huxley.mitre.org>
To: jinx%hpesogg@sde.hp.com
Cc: rrrs-authors@life.ai.mit.edu
Subject: Re: Revised WITH-VALUES and VALUES (I think we are near agreement!)
In-Reply-To: Your message of Thu, 24 Aug 89 16:22:48 -0700.
<8908242323.AA06076@sde.hp.com>
Date: Fri, 25 Aug 89 14:26:35 EDT
>> From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
>>
>> The meaning of "is an error" is that the program is incorrect, but the
>> implementation may not signal the violation. This goes very much
>> against the grain of what I want, since it says that the program was
>> illegal in the first place.
>>
I didn't think you would like the "is an error" part. Maybe now you
will appreciate the fact that in a previous proposal, nothing was said
about what happens in the case in which zero values or more than one
value are returned to something other than a receiving procedure. By
saying nothing about that case, programs which rely on the truncation
of multiple values are not labeled as being illegal, but not all
implementations are required to run those programs. In a nut shell, I
think that is the essence of the compromise. Given that
clarification, please reconsider the proposal in which the following
sentence:
Values applied to one argument simply returns its argument.
replaces the paragraph:
Values applied to one argument simply returns its argument.
Returning zero values or more than one value to something other
than a receiving procedure is an error.
If this proposal is not to your liking, please submit a replacement
paragraph which is consistant with the notation and terminology of
R3.95RS.
John
∂25-Aug-89 1221 jinx@hpesogg.hp.com Revised WITH-VALUES and VALUES (I think we are near agreement!)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Aug 89 12:20:55 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA06214; Fri, 25 Aug 89 14:57:14 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA05933; Thu, 24 Aug 89 16:18:53 pdt
Message-Id: <8908242318.AA05933@sde.hp.com>
Received: by hpesogg; Thu, 24 Aug 89 16:18:12 pdt
Date: Thu, 24 Aug 89 16:18:12 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Thu, 24 Aug 89 07:39:19 EDT <8908241139.AA10826@huxley.mitre.org>
Subject: Revised WITH-VALUES and VALUES (I think we are near agreement!)
Reply-To: jinx%hpesogg@sde.hp.com
Values applied to one argument simply returns its argument. Returning
more than one value or zero values to something other than a receiving
procedure is an error.
Isn't this saying that it is an error to return 2 values to an
implicit continuation? If so, I don't like it.
∂25-Aug-89 1234 ramsdell@linus.mitre.org "is an error" -> "is undefined"
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Aug 89 12:34:20 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA06306; Fri, 25 Aug 89 15:07:06 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA28665; Fri, 25 Aug 89 15:08:12 EDT
Posted-Date: Fri, 25 Aug 89 15:01:55 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA14518; Fri, 25 Aug 89 15:01:56 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908251901.AA14518@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: "is an error" -> "is undefined"
In-Reply-To: Your message of Fri, 25 Aug 89 14:51:00 -0400.
<19890825185146.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Fri, 25 Aug 89 15:01:55 EDT
>> From: ramsdell@linus.MITRE.ORG
...
>> If this proposal is not to your liking, please submit a replacement
>> paragraph which is consistant with the notation and terminology of
>> R3.95RS.
>>
>> John
I was wrong to be so restrictive. Kent M Pitman is right about the
alternative possibility of you proposing new notation and terminology
to cover this case. That is, maybe by replacing the phrase "is an
error" with "is undefined", and adding the appropriate definition of
"is undefined", we will have a proposal acceptable to all.
John
∂25-Aug-89 1237 KMP@stony-brook.scrc.symbolics.com Revised WITH-VALUES and VALUES (I think we are near agreement!)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Aug 89 12:36:37 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM by life.ai.mit.edu (4.1/AI-4.10) id AA06151; Fri, 25 Aug 89 14:51:25 EDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 647500; 25 Aug 89 14:51:59 EDT
Date: Fri, 25 Aug 89 14:51 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: Revised WITH-VALUES and VALUES (I think we are near agreement!)
To: jinx%hpesogg@sde.hp.com
Cc: ramsdell@linus.mitre.org, rrrs-authors@life.ai.mit.edu
In-Reply-To: <8908242323.AA06076@sde.hp.com>
Message-Id: <19890825185146.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Thu, 24 Aug 89 16:22:48 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: ramsdell@linus.mitre.org
I must use the phrase "an error"
to describe situations in which some implementations can signal an
error, and others do not have to.
The meaning of "is an error" is that the program is incorrect, but the
implementation may not signal the violation. This goes very much
against the grain of what I want, since it says that the program was
illegal in the first place.
I would rather say that the implementation may report the violation of
an implementation restriction (just like in the numeric section). The
program is not in error, neither is the implementation, there is
purely a mismatch.
Any encoding of information (such as an English sentence or a computer
program) must have -implicit- in it an encoding strategy. You cannot
say "oh, and by the way, this sentence is in English" at the end of a
sentence because that phrase may be interpreted differently in another
language. In the end, it's a grand leap of faith that anyone ever
understands anything anyone else says.
By my terminology, a mismatch can occur only when someone tries to run
an interpreter on a piece of code that it was not intended to be run on.
e.g.,
(PRINT (+ (VALUES 1 2) 3))
If you try to evaluate it in Scheme and it gives you an error, someone
in the office nearby might be right for saying "You dummy. That file was
named foo.lisp, not foo.scheme. It was never intended to work there.
You have a program/language mismatch."
By my terminology, once you've established the dialect which you believe
should be used to interpret the sentences in your language, it is
appropriate to call those things which are not well-defined `errors.'
Calling them errors does not entail signalling an error because the
behavior in an error situation need not be well-defined. It is this
property which allows you to establish a conforming processor of Scheme
which also supports an interesting superset.
My assumption is that you are really just fearing that saying that such
an expression "is an error" means that you are precluded from defining
it in a superset, which I don't think is Ramsdell's intent.
Btw, in our work on ANSI CL, we found the phrase "is an error" to be too
broad for practical purposes. It is well-defined, but it spans a number
of cases which people would like to be distinct. Mostly it does not
distinguish between cases where you left something undefined for
efficiency reasons (e.g., it might be too hard to check type information
on + in code compiled for speed) vs something you left undefined because
two stubborn factions couldn't agree (e.g., this issue of truncating
VALUES).
The net result for Common Lisp was that the old CLtL "is an error"
terminology will be replaced in ANSI CL by a whole bunch of new terms,
which cover the same turf in more refined fashion. The phrase "is an
error" will still have meaning in ANSI CL, but it will be a synonym for
the new and more preferred phrase "is undefined"--and it still fails to
distinguish the intent of leaving something undefined. To fix that, we
added more specific terms which we try to use where appropriate. e.g.,
"should signal an error" was introduced as a refinement of "is an error"
for cases where implementations are not free to extend the functionality
and where they must detect and signal the error when code is processed
in the highest safety setting. There are several other such refined
phrases which attempt to offer more intent about why something is
undefined. I could pass along the current draft meanings of those terms
if anyone on Scheme was serious about establishing some more refined
error terminology.
[Also, my AI Lab working paper ``Exceptional Situations In Lisp'' deals
at more length and with much greater clarity on some of these issues
than I have done here. Anyone interested in a copy can send me mail
privately with their address and I'll try to mail them a copy--I don't
think MIT still stocks it since it was only a working paper and never
promoted to memo status.]
∂25-Aug-89 1726 jinx@hpesogg.hp.com "is an error" -> "is undefined"
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Aug 89 17:25:58 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA09646; Fri, 25 Aug 89 19:51:06 EDT
Received: from hpesogr.cup.hp.com by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA09599; Fri, 25 Aug 89 16:49:55 pdt
Message-Id: <8908252349.AA09599@sde.hp.com>
Received: by hpesogg; Fri, 25 Aug 89 16:49:11 pdt
Date: Fri, 25 Aug 89 16:49:11 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: ramsdell@linus.mitre.org's message of Fri, 25 Aug 89 15:01:55 EDT <8908251901.AA14518@huxley.mitre.org>
Subject: "is an error" -> "is undefined"
Reply-To: jinx%hpesogg@sde.hp.com
I was wrong to be so restrictive. Kent M Pitman is right about the
alternative possibility of you proposing new notation and terminology
to cover this case. That is, maybe by replacing the phrase "is an
error" with "is undefined", and adding the appropriate definition of
"is undefined", we will have a proposal acceptable to all.
Undefined is fine with me. I previously suggested the possibility of
phrasing it as an implementation restriction. That would also be
fine.
I definitely do not want anything about an error said.
∂25-Aug-89 1749 jinx@hpesogg.hp.com Revised WITH-VALUES and VALUES (I think we are near agreement!)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Aug 89 17:48:18 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA09774; Fri, 25 Aug 89 20:13:38 EDT
Received: from hpesogr.cup.hp.com by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA10613; Fri, 25 Aug 89 17:12:58 pdt
Message-Id: <8908260012.AA10613@sde.hp.com>
Received: by hpesogg; Fri, 25 Aug 89 17:12:16 pdt
Date: Fri, 25 Aug 89 17:12:16 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: ramsdell@linus.mitre.org, rrrs-authors@life.ai.mit.edu
In-Reply-To: Kent M Pitman's message of Fri, 25 Aug 89 14:51 EDT <19890825185146.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Revised WITH-VALUES and VALUES (I think we are near agreement!)
Reply-To: jinx%hpesogg@sde.hp.com
I would rather say that the implementation may report the violation of
an implementation restriction (just like in the numeric section). The
program is not in error, neither is the implementation, there is
purely a mismatch.
Any encoding of information (such as an English sentence or a computer
program) must have -implicit- in it an encoding strategy. You cannot
say "oh, and by the way, this sentence is in English" at the end of a
sentence because that phrase may be interpreted differently in another
language. In the end, it's a grand leap of faith that anyone ever
understands anything anyone else says.
By my terminology, a mismatch can occur only when someone tries to run
an interpreter on a piece of code that it was not intended to be run on.
e.g.,
(PRINT (+ (VALUES 1 2) 3))
If you try to evaluate it in Scheme and it gives you an error, someone
in the office nearby might be right for saying "You dummy. That file was
named foo.lisp, not foo.scheme. It was never intended to work there.
You have a program/language mismatch."
Hah? I did not suggest a particular wording. I suggested something
like what I would like to see. I would have written it in a different
paragraph or in double quotes if I intended those exact words to be
used. I know that I'm not good at choosing words.
My assumption is that you are really just fearing that saying that such
an expression "is an error" means that you are precluded from defining
it in a superset, which I don't think is Ramsdell's intent.
R3RS (and I think R3.95RS, but I don't have a copy with me) defines "is
an error" as
When speaking of an error situation, this report uses the phrase "an
error is signalled" to indicate that implementations must detect and
report the error. If such wording does not appear in the discussion
of an error, then implementations are not required to detect or report
the error, though they are encouraged to do so. An error situation
that implementations are not required to detect is usually referred to
simply as "an error".
Thus if the reports defines something to be an error, a user has a
right to claim that I am sloppy or lax if I don't detect it, although
it may be my right.
I want no such connotation associated with returning one more than one
value to an implicit continuation.
That is why I raised the possibility of phrasing it as the violation
of an implementation restriction, which R3.95RS already defines for
numeric "mismatches".
Defining further terminology, or using unspecified or undefined is
fine by me.
∂25-Aug-89 2303 @mc.lcs.mit.edu:bawden.pa@xerox.com Numbers and Pork Rinds
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Aug 89 23:03:38 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA13142; Sat, 26 Aug 89 01:48:15 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11321;
25 Aug 89 2:21 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Aug 89 02:21:50 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa11315; 25 Aug 89 2:20 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 24 AUG 89 23:13:15 PDT
Date: Thu, 24 Aug 89 17:37 PDT
From: bawden.pa@xerox.com
Subject: Numbers and Pork Rinds
To: gls@think.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8908241628.AA00798@verdi.think.com>
Message-Id: <19890825003740.7.ALAN@ROCKY.parc.xerox.com>
Line-Fold: no
Date: Thu, 24 Aug 89 12:28:42 EDT
From: gls@Think.COM (Guy Steele)
Date: Wed, 23 Aug 89 17:33 PDT
From: bawden.pa@xerox.com
(MAX #<Interval 3 through 5> 10) ==> 10
(MAX #<Interval 9 through 11> 10) ==> #<Interval 10 through 11>
BUT IN THE CASE WHERE FLOATING POINT IS USED I do not believe there is any
case where an exact answer may be returned if one of the arguments is
inexact.
Very well; we are making progress. You do admit that in some circumstances,
in some implementations, it may make sense for (max 4.0 1000) to return an
exact 1000, say in the case where "4.0" is interpreted by the reader to
mean "the interval from 3.95 to 4.05".
This is not a new admission on my part. I'm pretty sure I've be saying
parenthetically all along that if you use interval arithmetic you might be
able to return an exact answer. I may have slacked off on beating that
particular point recently because it gets rather tiresome to be constantly
decorating my arguments with little qualifications of the form: "(assuming
we are using floating point)" and "(unless you are using interval
arithmetic or continued fractions)".
My argument, then, is as follows. Floating-point is indeed so screwed up
that the implementor cannot a priori regard them as intervals or as
anything else interesting, and therefore cannot return an exact result for
the supremum operation. HOWEVER, in some cases the user, knowing the
properties of the floating-point arithmetic, can with his additional
understanding determine that they may be regarded as intervals (or
something close to that) for his purposes. Therefore the user should be
given a choice. LARGEST and SMALLEST may be useful alternatives; *but* I
have also managed to argue that their use is not portable. (On the other
hand, many uses of inexact arithmetic will be nonportable in precisely the
same manner, so to this we should not attach too great a stigma.)
No only are uses of LARGEST and SMALLEST non-portable, but LARGEST and
SMALLEST are also very easy for the user to write himself. In fact, a user
with a sufficient understanding of the properties of the inexact arithmetic
in a given implementation may be able to write all kinds of non-portable
things that work correctly to solve his problem -- but that doesn't mean
that we should be putting such things in the language.
... We aren't specifying the behavior of inexact numbers here.
If inexactness is considered by the Scheme standard merely to be a
scarlet letter indicating that a value is in a state of sin and is
therefore not to be trusted (for inexact arithmetic, while required to
strive for "high quality", has no particular portable requirements),
then I want to know how it is that you can ever think that "perhaps
1000" can ever be said rather than merely "perhaps"; in other words,
without some further requirements on, or knowledge of, the quality of a
particular implementation, why is it not my duty to regard *every*
inexact number as representing merely "perhaps"?
In the absence of any other constraints on the behavior of inexact numbers,
an implementation in which there is just -one- inexact number would be
legal. We could even call it "perhaps". I'm not sure this would be any
more useful than an implementation that didn't have any inexacts at all and
signalled an error when it couldn't produce an exact answer. Now I don't
recall what set of constraints are currently in the draft report, but there
was a time when some language ruled out having just #<Perhaps>. But none
of this has anything to do with the issue of MAX/MIN, which is purely a
consequence of the desired properties of -exact- numbers.
All I care about is that MAX not return an exact answer unless the
implementation really -knows- that that exact number is the correct answer.
That's all I care about. Read my lips.
Okay. Up to now I had understood you additionally to argue that
the implementation can't ever know that for LARGEST, and therefore
LARGEST is a bogus concept.
See above. I have tried very hard to -never- say that the implementation
"can't ever know" anything without qualifying it by saying: "assuming
floating point". I don't know what it means for LARGEST to be a "bogus
concept". All I know is that it isn't the right procedure to give to the
users as MAX.
Now that we have found a circumstance
when the implementation *can* know, we have proved that LARGEST is
not bogus.
Huh? The circumstances when the -implementation- can know the exact result
from a call to MAX with an inexact argument are when something other than
floating point is being used. But what does this have to do with LARGEST?
I don't follow this.
A separate argument now concerns whether it is useless.
Since the user can write it himself so easily it better be pretty damn
usefull before we should put it in the language.
But I think I am about to run out of steam. Alan and I have aired
our views pretty thoroughly, tying up a lot of mailboxes in the process.
Hey, all you out there: does anyone else care? Has anyone's mind been
changed as a result of our discussion?
I'll bet most people haven't been paying attention. I fully expect to have
to repeat this entire argument every six months for the rest of my life.
∂26-Aug-89 0100 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com Programmer-defined data types
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Aug 89 01:00:52 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00440; Sat, 26 Aug 89 03:53:25 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16162;
25 Aug 89 11:46 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Aug 89 11:46:50 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa16101;
25 Aug 89 11:41 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04102; Fri, 25 Aug 89 11:41:08 EDT
Received: from RELAY.CS.NET (relay.cs.net) by zurich.ai.mit.edu; Fri, 25 Aug 89 11:37:55 edt
Received: from tektronix.tek.com by RELAY.CS.NET id aa07728; 25 Aug 89 11:40 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA11688; Fri, 25 Aug 89 08:42:51 PDT
Received: by tekirl.labs.tek.com (5.51/7.1)
id AA21006; Fri, 25 Aug 89 08:40:41 PDT
Received: by tekchips.LABS.TEK.COM (5.51/6.24)
id AA15105; Fri, 25 Aug 89 08:43:10 PDT
Date: Fri, 25 Aug 89 08:43:10 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Message-Id: <8908251543.AA15105@tekchips.LABS.TEK.COM>
To: RRRS-Authors@zurich.ai.mit.edu
Subject: Programmer-defined data types
This is a resend - I don't think I have seen this message come through
Date: Mon, 21 Aug 89 15:48:14 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Message-Id: <8908212248.AA18203@tekchips.LABS.TEK.COM>
To: RRRS-Authors@zurich.ai.mit.edu
Cc: Pavel.pa@xerox.com
Subject: Programmer-defined data types
I support Pavel's proposal for records.
I would prefer that each abstraction-breaking procedure is identified as
such in its description. I prefer the term "field" to "slot."
-- Should there be a RECORD-COPIER procedure? Some folks would like to
have one for performance and convenience..
I can think of many operations generic to records. I don't think
copying deserves to be a special case.
-Norman
In addition, I concur with Alan's preference for a second argument
(a list of field names) to RECORD-CONSTRUCTOR.
∂26-Aug-89 0315 @mc.lcs.mit.edu,@life.ai.mit.edu:KMP@stony-brook.scrc.symbolics.com Programmer-defined data types
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Aug 89 03:15:25 PDT
Received: from MINTAKA.LCS.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB00962; Sat, 26 Aug 89 06:01:33 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17208;
25 Aug 89 13:23 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Aug 89 13:23:08 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa17188;
25 Aug 89 13:21 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA05011; Fri, 25 Aug 89 13:21:12 EDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (stony-brook.scrc.symbolics.com) by zurich.ai.mit.edu; Fri, 25 Aug 89 13:16:56 edt
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 647383; 25 Aug 89 12:39:51 EDT
Date: Fri, 25 Aug 89 12:39 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: Programmer-defined data types
To: cph@zurich.ai.mit.edu
Cc: bawden.pa@xerox.com, Pavel.pa@xerox.com, RRRS-Authors@zurich.ai.mit.edu,
KMP@stony-brook.scrc.symbolics.com
In-Reply-To: <8908241555.AA11386@zurich.ai.mit.edu>
Message-Id: <19890825163937.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Thu, 24 Aug 89 11:55:21 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Date: Mon, 21 Aug 89 11:34 PDT
From: bawden.pa@xerox.com
Line-Fold: no
Date: Fri, 18 Aug 89 18:36:26 PDT
From: Pavel.pa@Xerox.COM
(RECORD-CONSTRUCTOR rtd)
Returns a procedure for constructing new members of the type represented by
rtd. The returned procedure accepts exactly as many arguments as there
were slot-names in the call to MAKE-RECORD-TYPE that created the type
represented by rtd; these are used, in order, as the initial values of
those slots in a new record, which is returned by the constructor
procedure.
I prefer the alternative that someone (RRJ?) made the last time we
discussed this:
(RECORD-CONSTRUCTOR rtd slot-names)
Where slot-names is a subset of the slot-names given to MAKE-RECORD-TYPE.
The returned procedure accepts exactly as many arguments as there are
slot-names. It creates a new record and initializes the specified slots.
I agree with this wholeheartedly. I think this form of the
constructor-constructor is significantly more useful. ...
I think you might want to allow a way to initialize the other arguments.
There are several ways you might want to do this, depending on how many
cases you want to handle and how convenient you want them to be:
- If you want to say initial values can't depend on one another, an
alist suffices. e.g.,
(DEFINE FOO (MAKE-RECORD-TYPE 'FOO '(A B C D)))
(DEFINE MAKE-FOO (RECORD-CONSTRUCTOR FOO '(A B C) '((D 0))))
- If you want to say initial values can depend on one another, but
beyond that, there are no ongoing constraints...
(DEFINE PERSON (MAKE-RECORD-TYPE 'PERSON '(HAIR-COLOR EYE-COLOR)))
(DEFINE HAIR-COLOR (RECORD-ACCESSOR PERSON 'HAIR-COLOR))
(DEFINE SET-HAIR-COLOR (RECORD-UPDATER PERSON 'HAIR-COLOR))
(DEFINE EYE-COLOR (RECORD-ACCESSOR PERSON 'EYE-COLOR))
(DEFINE SET-EYE-COLOR (RECORD-UPDATER PERSON 'EYE-COLOR))
(DEFINE MAKE-PERSON
(RECORD-CONSTRUCTOR
PERSON '(HAIR-COLOR)
(LAMBDA (PERSON)
(IF (MEMQ (HAIR-COLOR PERSON) '(BROWN BLACK))
(SET-EYE-COLOR PERSON 'BROWN)
(SET-EYE-COLOR PERSON 'BLUE)))))
- If you want to say initial values can depend on one another on
an ongoing basis, you have to extend the formalism further somehow.
To explain this, I'll show you a buggy example and you can ponder
how to fix it...
(DEFINE POSITION
(MAKE-RECORD-TYPE 'POSITION '(X Y Z CACHED-DISTANCE-FROM-ORIGIN)))
(DEFINE X-POSITION (RECORD-ACCESSOR POSITION 'X))
(DEFINE SET-X-POSITION (RECORD-UPDATER POSITION 'X))
(DEFINE Y-POSITION (RECORD-ACCESSOR POSITION 'Y))
(DEFINE SET-Y-POSITION (RECORD-UPDATER POSITION 'Y))
(DEFINE Z-POSITION (RECORD-ACCESSOR POSITION 'Z))
(DEFINE SET-Z-POSITION (RECORD-UPDATER POSITION 'Z))
(DEFINE DISTANCE-FROM-ORIGIN
(RECORD-ACCESSOR POSITION 'CACHED-DISTANCE-FROM-ORIGIN))
(DEFINE SET-DISTANCE-FROM-ORIGIN
(RECORD-UPDATER POSITION 'CACHED-DISTANCE-FROM-ORIGIN))
(DEFINE (UPDATE-DISTANCE-FROM-ORIGIN RECORD)
(SET-DISTANCE-FROM-ORIGIN
RECORD (SQRT (EXPT (X-POSITION RECORD) 2)
(EXPT (Y-POSITION RECORD) 2)
(EXPT (Z-POSITION RECORD) 2))))
(DEFINE MAKE-POSITION
(RECORD-CONSTRUCTOR POSITION '(X Y Z)
UPDATE-DISTANCE-FROM-ORIGIN))
The problem here is that every time you want to update X-, Y-, or
Z-POSITION, you will have to update CACHED-DISTANCE-FROM-ORIGIN and
there's no way to say that. A possible fix would be to generalize
RECORD-UPDATER to take a similar argument, which was run to make any
updates to `hidden' slots after the main assignment was done. If
you did this, though, it would be necessary to generalize RECORD-UPDATER
to take a list of slot names, rather than a single slot, so that the
function didn't get run multiple times when you were trying to update
several slots in parallel. e.g.,
(RECORD-UPDATER '(X Y Z) UPDATE-DISTANCE-FROM-ORIGIN)
would return you a function of four arguments, a record and new
values for X, Y and Z. Every time you called it, it would not only
set the values but would run the function which updated the hidden
slot.
This use of a function to run after assignment has been done is very
common in Flavors, by the way. Of course, there it's done as part of
a more general mechanism that no one is proposing here. But this simple
level of functionality offers an important hook that can be very powerful.
And it doesn't cost anyone anything if they're not using it.
Btw, if you change RECORD-UPDATER to require (or permit) a list, you
might want to make an analogous change to RECORD-ACCESSOR. In which
case multiple values are the likely thing to want to return.
[Now you can talk about this record stuff without feeling like you're
interrupting the multiple values discussion. :-]
If you do, then you're short a piece of language glue. Consider uses
like:
;Apparent idiom for copying slots from RECORD1 to RECORD2
(LAMBDA (RECORD1 RECORD2)
(WITH-VALUES
((RECORD-ACESSOR POSITION '(X Y Z)) RECORD2) ;returns 3 values
(LAMBDA (NEW-X NEW-Y NEW-Z)
((RECORD-UPDATER POSITION '(X Y Z)) RECORD1 NEW-X NEW-Y NEW-Z))))
There is too much gratuitous glue needed to stick this together, which is
an indictment of WITH-VALUES, if you ask me. I'll show how
COMPOSE-CONTINUATION could generalize to solve the problem, and then return
to why WITH-VALUES isn't so good. Suppose we permit:
(COMPOSE-CONTINUATION receiver arg1 ... argN generator)
where arg1...argN were something to interpose in the values stream, permitting
me to write:
(COMPOSE-CONTINUATION CONS 1 (LAMBDA () 2)) => (1 . 2)
Getting back to the example, I could write the above idiom as:
(LAMBDA (RECORD1 RECORD2)
(COMPOSE-CONTINUATION
(RECORD-UPDATER POSITION '(X Y Z))
RECORD2
((RECORD-ACESSOR POSITION '(X Y Z)) RECORD1)))
Personally, i think this feels about as good as it could be. Certainly I see
no wasted words, and the language glue permits the multi-valued functions to
snap together as they need to--an important property of language glue.
The proposed WITH-VALUES primitive doesn't seem to give me similar control.
The only `syntactic room' for extra arguments in WITH-VALUES is after the first
two arguments, so I would have to extend it as
(WITH-VALUES generator receiver arg1 arg2 ...)
which would mean that the interposed argument, RECORD, would not be in the
same order as it would appear in the values stream, writing the same idiom
from above as:
(LAMBDA (RECORD1 RECORD2)
(WITH-VALUES
((RECORD-ACESSOR POSITION '(X Y Z)) RECORD1)
(RECORD-UPDATER POSITION '(X Y Z))
RECORD2))
or it would mean that the updater needed to be changed to takes its RECORD
argument last. I don't like either of these solutions. And I do think the
need to interpose new items into the data-flow path is a common one (that
correctly led to the generalization of APPLY from a 2-argument function in
Maclisp to a multi-arg function in Common Lisp), so I think it's something
the designers of WITH-VALUES would do well to think carefully about.
∂26-Aug-89 0529 @mc.lcs.mit.edu:harrison@s45.csrd.uiuc.edu Numbers and Pork Rinds
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Aug 89 05:29:49 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01884; Sat, 26 Aug 89 08:05:28 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17514;
25 Aug 89 13:52 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Aug 89 13:52:44 EDT
Received: from [128.174.132.2] by mintaka.lcs.mit.edu id aa17279;
25 Aug 89 13:30 EDT
Received: from s45.csrd.uiuc.edu by uicsrd.csrd.uiuc.edu with SMTP
(5.61+/IDA-1.2.8) id AA20309; Fri, 25 Aug 89 12:30:43 -0500
Received: by s45.csrd.uiuc.edu (3.2/9.2)
id AA19968; Fri, 25 Aug 89 10:30:39 PDT
Date: Fri, 25 Aug 89 10:30:39 PDT
From: Luddy Harrison <harrison@s45.csrd.uiuc.edu>
Message-Id: <8908251730.AA19968@s45.csrd.uiuc.edu>
To: gls@think.com
Cc: bawden.pa@xerox.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Guy Steele's message of Thu, 24 Aug 89 12:28:42 EDT <8908241628.AA00798@verdi.think.com>
Subject: Numbers and Pork Rinds
>Hey, all you out there: does anyone else care? Has anyone's mind been
>changed as a result of our discussion?
Yes. I have but a minor comment to make. Alan, the inexactness you
attribute to floating point numbers is not a property of the
representation itself, but rather its interpretation (as a projection
of the space of real values). I, knowing the algebra of a floating
point implementation, may certainly write down an "exact" computation
in terms of floating point values. For example: (+ 2.0 3.0). Knowing
that by 2.0 and 3.0 I mean exactly 2 and 3, and knowing
the floating point unit of my machine, I know that the 5.0 that
results will be an "exact" result.
By the same token, I may write down an "inexact" computation in
terms of integers. For example, let H be a procedure that
heuristically evaluates a chess position and returns an integer
representing the goodness of the position. I interpret H's return
value as an interval, a distribution, around the "real" goodness of
the board. Now, when I write (max (H board-1) (H board-2)), I don't
expect max to understand that its arguments are grossly lacking in
precision. Neither would I expect it to do so if H returned a
floating point value. It is my job to determine the MEANING of the
representations I ask the computer to manipulate; I want only for the
computer to act predicatably upon the representations. Predictably,
in the case of floating point values, has traditionally meant that the
computer behaves as though the values were exact.
-Luddy Harrison
∂26-Aug-89 0532 @mc.lcs.mit.edu,@hp-sde.sde.hp.com:jinx@hpesogg.hp.com Numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Aug 89 05:31:59 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01892; Sat, 26 Aug 89 08:08:58 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18900;
25 Aug 89 15:36 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Aug 89 15:36:23 EDT
Received: from hp-sde.sde.hp.com by mintaka.lcs.mit.edu id aa18864;
25 Aug 89 15:33 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA29730; Thu, 24 Aug 89 11:36:29 pdt
Message-Id: <8908241836.AA29730@sde.hp.com>
Received: by hpesogg; Thu, 24 Aug 89 11:35:48 pdt
Date: Thu, 24 Aug 89 11:35:48 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: bawden.pa@xerox.com
Cc: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: bawden.pa@xerox.com's message of Mon, 21 Aug 89 17:24 PDT <19890822002405.2.ALAN@ROCKY.parc.xerox.com>
Subject: Numbers
Reply-To: jinx%hpesogg@sde.hp.com
Now I'm sure that about half of you are shouting at your terminal about how
I couldn't -possibly- mean that, but I do. Understand me once and for all:
INEXACT NUMBERS ARE NOT NUMBERS
INEXACT NUMBERS ARE NOT NUMBERS
INEXACT NUMBERS ARE NOT NUMBERS
They do not obey the rules followed by numbers, because they cannot.
Inexact numbers only represent our -approximate- -knowledge- about numbers.
In
(max 1.0 549755813889) ==> 549755813888.0
we strongly suspect that the first number is 1, but we don't know for sure.
Thus we strongly suspect that the answer is 549755813889, but again we
don't know for sure (the first number could have actually been
549755813890). Since we don't know the answer for sure, we must return an
inexact representation of our best guess. 549755813888.0 is the closest we
can come. (The next larger might be 549755879424.0, assuming 23 bits of
floating point precision, which is not very close at all.)
I'd rather see SUP/MAX reutrn the larger answer, than the numerically
closer answer. I use MAX rarely, and I think I've always intended it
to mean "something no smaller than any of its arguments".
Indeed, we could -specify- that MAX always ``round up'' in the inexact case
so that the result always appears greater (accroding to `<') than any of
the arguments. This would be similar to specifying that `<' must always
behave transitively. It would be a feeble attempt on our part to paper
over the ugly fact that -in- -general-, inexact numbers do not obey the
axioms of arithmetic.
However feeble, it would provide for a somewhat more intuitive and
predictable model. In the absence of detailed information about the
representation(s) of inexact numbers in a given implementation, and
the rounding algorithms using by min/max, I can't expect anything in
particular about the result value using your (and Will's) model.
Using the feeble constraint, I can at least bound the result.
∂27-Aug-89 0028 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu Multiple values for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Aug 89 00:28:36 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00280; Sun, 27 Aug 89 03:14:24 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01990;
26 Aug 89 18:01 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Aug 89 17:44:23 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24285;
26 Aug 89 0:20 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA12480; Sat, 26 Aug 89 00:20:08 EDT
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Sat, 26 Aug 89 00:16:51 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA03202; Fri, 25 Aug 89 21:18:36 PDT
Received: by spencer.cs.uoregon.edu; Fri, 25 Aug 89 21:18:22 PDT
Date: Fri, 25 Aug 89 21:18:22 PDT
From: will@cs.uoregon.edu
Message-Id: <8908260418.AA19329@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Multiple values for R4RS
Cc: dyb@iuvax.cs.indiana.edu
Permit me a few remarks on how the Scheme reports have said what is
best left unsaid, and then I will explain why it is important to me
that (VALUES E) be the same as E.
Bill Rozas:
Undefined is fine with me. I previously suggested the possibility of
phrasing it as an implementation restriction. That would also be
fine.
What you want to say is that "the effect is unspecified" or (speaking
of a procedure) "its behavior is implementation dependent". For
examples of both, see the description of WITH-INPUT-FROM-FILE.
"Undefined" is bad because it has a definite meaning in Scheme: if the
value of a variable is undefined, then it is an error to reference that
variable. The use of undefined as an actual value is explicit in section
7.2 and is almost explicit in section 7.3. "Implementation restrictions"
are discouraged, which may be the effect you want in this case but would
not be likely to make your political opponent(s) happy.
Kent Pitman:
The net result for Common Lisp was that the old CLtL "is an error"
terminology will be replaced in ANSI CL by a whole bunch of new terms,
which cover the same turf in more refined fashion....I could pass along
the current draft meanings of those terms if anyone on Scheme was
serious about establishing some more refined error terminology.
I looked at the new CL terminology and decided not to use it, though
I added the notion of an implementation restriction.
I don't think a more refined error terminology would help us much.
In the last couple of days I've read about ten messages debating
Returning zero values or more than one value to something other
than a receiving procedure is an error.
versus something like
The effect of returning zero values or more than one value to
something other than a receiving procedure is unspecified.
when the real sticking point, as I see it, is the one-value case:
Kent Dybvig:
As an implementor, I would like to signal an error whenever someone
attempts to return (values ...) to a context where multiple values
aren't expected, or something other than (values ...) to a context
expecting multiple values. Requiring "(values e)" to be the same as
"e" makes it impossible to do this. As you pointed out in your note,
this won't affect anyone who doesn't like this behavior, since they
can always create their own versions of "values" and "with-values"
that circumvent the error checks.
The reason I don't like a semantics in which (VALUES E) is not required
to be the same as E doesn't have anything to do with whether I can
implement the semantics I like (I can, regardless). It has a little bit
to do with whether I can write certain portable programs (see example
below), but not much. It mainly has to do with the complexity of Scheme
considered as a programming language independent of its implementations.
The only way that I can see to understand or explain a semantics in
which (VALUES E) is not required to be the same as E is to postulate
an entirely new kind of object whose sole purpose is to communicate
between VALUES and receivers of multiple values. I then have to say
that the effect is undefined (or an error) if this new kind of object
ever gets passed to an ordinary continuation, procedure, or special
form (e.g. IF). That's a considerable amount of intellectual overhead
if the only reason for it is to allow some particular implementation
"to signal an error whenever someone attempts to return (VALUES ...)
to a context where multiple values aren't expected, or something other
than (VALUES ...) to a context expecting multiple values".
I think anyone who wants to impose this extra semantic complexity on
Scheme as the price for multiple values ought to explain why it is so
desirable for an implementation to signal an error in the circumstances
just described.
Here's an example of a potentially useful procedure that would be
less useful if (VALUES E) is not required to be the same as E:
; Given two procedures F and G, COMPOSE returns a procedure that
; acts as the composition of F and G. The arguments to F consist
; of all the values returned by G.
(define (compose f g)
(lambda args
(receive-values (lambda () (apply g args))
(lambda results (apply f results)))))
(define h1 (compose (lambda (x) (+ x 1)) *))
(h1 3 4) ==> 13
(define h2 (compose + (lambda (x y) (values (* 2 x) (+ y 1)))))
(h2 3 4) ==> 11
Kent Dybvig:
And this is the feature I'm most critical of. Unless an implementation
does support the truncation feature, I don't see any reason why we should
require that "(values e)" be equivalent to "e". I would like to feel
free to signal an error if "(values e)" is returned to a context that
is not prepared to accept multiple values.
I have given two reasons in this message, both of which are independent
of the truncation feature. I'm curious to know what you think of them,
and even more curious to know why signalling that error is so important
to you.
Incidentally, the proposed ACCEPTS? procedure also complicates the
language (because the denotations of procedures would have to carry
their arity), but the complication is fairly slight and the claimed
benefit is clearer. It is my impression that the benefit is about
as meager as the complication, but at least I understand the argument.
Also incidentally, the people who have been explaining how easy it
is to implement ACCEPTS? seem to have been assuming that the Scheme
implementor has control over the calling sequences and/or compilers.
It's not so easy if your goal is to build a Scheme system that uses
standard calling sequences and can call separately compiled C code
(say) without having to interpose a trampoline or other crock. That's
hard enough without having to define ACCEPTS? for unknown C procedures.
Peace, Will
∂27-Aug-89 1443 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu last call for MIN and MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Aug 89 14:42:53 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA03464; Sun, 27 Aug 89 17:24:11 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01993;
26 Aug 89 18:02 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Aug 89 17:44:30 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24289;
26 Aug 89 0:20 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA12483; Sat, 26 Aug 89 00:20:22 EDT
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Sat, 26 Aug 89 00:17:06 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AB03203; Fri, 25 Aug 89 21:19:53 PDT
Received: by spencer.cs.uoregon.edu; Fri, 25 Aug 89 21:19:45 PDT
Date: Fri, 25 Aug 89 21:19:45 PDT
From: will@cs.uoregon.edu
Message-Id: <8908260419.AA19333@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: last call for MIN and MAX
Guy "I Haven't Had So Much Fun While Trying to Be Serious in Years" Steele:
....I think that
when you speak of "exactness-preserving" you mean "inexactness-preserving",
and similarly "perfect rules of exactness" => "perfect rules of
inexactness" which is then seen to be a contradiction in terms.
That just goes to show that a contradiction in terms isn't the same
as a contradiction. Exact numbers are like original works of art;
they're not worth much unless they can be distinguished from forgeries.
Inexactness-preserving procedures, which stamp potential forgeries,
are the primary means for preserving the worth of exact numbers.
They're not perfect, because of the predicates and INEXACT->EXACT.
Despite its occasionally apocalyptic tone, this whole argument has been
about whether the pathologies inherent in an inexactness-preserving MIN
and MAX justify adding two more loopholes.
I think everyone who wants to understand this issue probably does by now,
and I assume that anyone who hasn't voted doesn't care.
Peace, Will
∂27-Aug-89 1647 @mc.lcs.mit.edu,@hp-sde.sde.hp.com:jinx@hpesogg.hp.com Numbers and Pork Rinds
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Aug 89 16:47:21 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04395; Sun, 27 Aug 89 19:36:13 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03119;
26 Aug 89 19:54 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Aug 89 19:52:13 EDT
Received: from hp-sde.sde.hp.com by mintaka.lcs.mit.edu id aa25737;
26 Aug 89 3:24 EDT
Received: from hpesogr.cup.hp.com by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA22725; Sat, 26 Aug 89 00:23:13 pdt
Message-Id: <8908260723.AA22725@sde.hp.com>
Received: by hpesogg; Sat, 26 Aug 89 00:22:29 pdt
Date: Sat, 26 Aug 89 00:22:29 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: bawden.pa@xerox.com
Cc: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: bawden.pa@xerox.com's message of Thu, 24 Aug 89 17:37 PDT <19890825003740.7.ALAN@ROCKY.parc.xerox.com>
Subject: Numbers and Pork Rinds
Reply-To: jinx%hpesogg@sde.hp.com
But I think I am about to run out of steam. Alan and I have aired
our views pretty thoroughly, tying up a lot of mailboxes in the process.
Hey, all you out there: does anyone else care? Has anyone's mind been
changed as a result of our discussion?
Some of us have been mostly quiet because Alan has been doing a good
job of representing what we've come to accept (I argued fiercely
against Alan's/Will's notion of MIN and MAX a few months ago at MIT,
but I saw the light later).
The only additional constraint that I would like to see is that
SUP/MAX round up and INF/MIN round down when the relevant extreme is
exact, the implementation cannot determine that an exact answer is
correct, and thus the returned answer must be inexact.
Since (by Alan's argument) it is not correct for SUP/MAX to return the
exact argument (except in those implementations that can prove that
the exact answer is in fact the SUP/MAX), we cannot expect that the
answer will always be = to one of the arguments. We can, however,
still provide an answer that is guaranteed to be no smaller. Hence
the constraint.
I'll bet most people haven't been paying attention. I fully expect to have
to repeat this entire argument every six months for the rest of my life.
No. Hopefully the archives will still be around, and you can just
mail the whole discussion. Perhaps if they make it through it they
deserve to discuss it with you.
∂27-Aug-89 1653 @mc.lcs.mit.edu:bawden@arisia.xerox.com Numbers and Pork Rinds
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Aug 89 16:53:11 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04408; Sun, 27 Aug 89 19:41:34 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12795;
27 Aug 89 17:42 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Aug 89 17:41:43 EDT
Received: from [13.1.100.206] by mintaka.lcs.mit.edu id aa12734;
27 Aug 89 17:34 EDT
Received: from roo.parc.Xerox.COM by arisia.xerox.com with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA02136; Sun, 27 Aug 89 14:29:25 -0700
Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA06045; Sun, 27 Aug 89 14:31:55 PDT
Date: Sun, 27 Aug 89 14:30 PDT
From: Alan Bawden <bawden@arisia.xerox.com>
Subject: Numbers and Pork Rinds
To: harrison@s45.csrd.uiuc.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8908251730.AA19968@s45.csrd.uiuc.edu>
Message-Id: <19890827213042.4.ALAN@MR-BUN.parc.xerox.com>
Date: Fri, 25 Aug 89 10:30:39 PDT
From: harrison@s45.csrd.uiuc.edu (Luddy Harrison)
... I have but a minor comment to make. Alan, the inexactness you
attribute to floating point numbers is not a property of the
representation itself, but rather its interpretation (as a projection
of the space of real values).
No, I don't myself "attribute" inexactness to floating point numbers at
all. In the context of the current discussion, the notion of an "inexact"
number has a purely technical meaning. An inexact number is a Scheme
object that the predicate INEXACT? is true of. It just so happens that the
most common technique for implementing inexact numbers is to use a floating
point representation (and not to use floating point for anything else), and
so in most Scheme implementations the two notions coincide.
This need not be the case.
Floating point numbers can be used as a representation for exact (rational)
numbers as well, if an implementation chooses. But since the set of
rationals represented exactly by floating point is not even approximately
closed under even the most common operations (consider (/ 1 3) or
(+ 1 1000000000000000000000000000000)), this doesn't seem to be a viable
choice.
Better is to play the game the other way, and use representations usually
used for exact numbers to represent inexact numbers. For example, A
convincing case can be made for using ratios to do inexact arithmetic.
(See the paper by Berthold Horn that describes this [an MIT AI Memo, I
think, I don't have my copy here].)
I, knowing the algebra of a floating
point implementation, may certainly write down an "exact" computation
in terms of floating point values. For example: (+ 2.0 3.0). Knowing
that by 2.0 and 3.0 I mean exactly 2 and 3, and knowing
the floating point unit of my machine, I know that the 5.0 that
results will be an "exact" result.
By the same token, I may write down an "inexact" computation in
terms of integers. For example, let H be a procedure that
heuristically evaluates a chess position and returns an integer
representing the goodness of the position. I interpret H's return
value as an interval, a distribution, around the "real" goodness of
the board. Now, when I write (max (H board-1) (H board-2)), I don't
expect max to understand that its arguments are grossly lacking in
precision. Neither would I expect it to do so if H returned a
floating point value.
This is all true, but doesn't address the issue of what happens if you
actually write a Scheme program to perform the computations you describe, and
then apply the predicates EXACT? and INEXACT? to the various Scheme objects
being manipulated. The "inexact" measure of the goodness of a particular
chess position may well be represented by a Scheme number that EXACT? is
true of. If you try and make the two notions of "exactness" coincide -- so
that INEXACT? will be true of all numbers that you know have a heuristic
derivation -- then most Scheme implementations will force you to be working
with floating point numbers.
It is my job to determine the MEANING of the
representations I ask the computer to manipulate; I want only for the
computer to act predicatably upon the representations. Predictably,
in the case of floating point values, has traditionally meant that the
computer behaves as though the values were exact.
On the machine I am using right now:
(/ 1.0 3.0) ==> 0.3333333432674407958984375
I suppose there is some sense in which this is "behaving as though the
values were exact". The value returned is in fact a -particular- rational
number. (It normally prints as "0.33333334" -- I have shown it here
printed precisely.) But it is not the -same- rational number that would be
returned in a different Scheme implementation, and it is not the same
rational number that a mathematician would compute with pencil and paper.
The sense of "inexact" that Scheme implements with its INEXACT? and EXACT?
predicates is that an exact number is an object that represents a
particular number, and that number was computed in such a way that the
implementation is certain that the -same- particular number would be
computed in any other implementation. The user can allow this condition to
become violated if he uses the procedure INEXACT->EXACT or any of the
numeric predicates. The current debate is about whether MAX and MIN also
allow this condition to become violated.
∂28-Aug-89 0455 ramsdell@linus.mitre.org Kent, please bless this multiple values proposal.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Aug 89 04:55:35 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA01704; Mon, 28 Aug 89 07:35:33 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA02853; Mon, 28 Aug 89 07:36:17 EDT
Posted-Date: Mon, 28 Aug 89 07:30:00 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA16873; Mon, 28 Aug 89 07:30:02 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908281130.AA16873@huxley.mitre.org>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
Subject: Kent, please bless this multiple values proposal.
In-Reply-To: Your message of Fri, 25 Aug 89 21:18:22 -0700.
<8908260418.AA19329@spencer.cs.uoregon.edu>
Date: Mon, 28 Aug 89 07:30:00 EDT
I believe I have a multiple values proposal acceptable to all. Given
the history of the Snowbird meeting, I ask you, Kent, to vote on this
proposal before I submit it to the rest of the authors. The essence
of the compromise is that we leave unspecified the effect of returning
zero values or more than one value to something other than a receiving
procedure. This means implementations may or may not signal an error
in this case, and both kinds of implementations are considered equally
correct. In an effort to reach compromise, others have given up their
requirement that some procedures such as ACCEPT? be included. In the
spirit of compromise, I hope you will give up your requirement that an
error may be signaled when a continuation expecting one value receives
one value from VALUEs.
John
--------------------------------
(values obj ...) essential procedure
Returns 0 or more values to a receiving procedure (See with-values).
(values) => returns zero (no) values
(values 1) => returns a single value, 1
(values 1 'a) => returns two values, 1 and the symbol a
Values applied to one argument simply returns its argument. The
effect of returning zero values or more than one value to something
other than a receiving procedure is unspecified.
(with-values generator receiver) essential procedure
Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with no arguments. It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator' or if 'generator' cannot be called with zero arguments.
(with-values
(lambda ()
(values 1 2))
cons) => (1 . 2)
--------------------------------
∂28-Aug-89 0925 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #189
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Aug 89 09:24:59 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA03736; Mon, 28 Aug 89 11:42:36 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16013;
28 Aug 89 0:34 EDT
Date: 28 AUG 89 00:07:41 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Subject: Scheme Digest #189
To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id: <8908280034.aa16013@mintaka.lcs.mit.edu>
Scheme Digest #189 28 AUG 89 00:07:41 EDT
Today's Topics:
How Good Is Xscheme?
----------------------------------------------------------------------
Date: 27 Aug 89 03:36:54 GMT
From: "Roger R. Espinosa" <att!cbnewse!macduff@bloom-beacon.mit.edu>
Subject: How Good Is Xscheme?
Message-Id: <772@cbnewse.ATT.COM>
Hi.
I'm doing a project in scheme (Hi, Cordy!), and in the course
of trying to keep down the long-distance-modeming (since I'm
in Naperthrill, IL right now, and the *official* scheme is back
in Ann Arbor, MI...), I ftp'ed my way around and found two scheme
systems: xscheme v.0.16, and mit-scheme, version 7.0.
NOW ... the problem is that the copy of mit-scheme which I ftp'ed
onto the sun then onto the Macintosh and then onto the UTS feels that
the *.Z file is corrupted (I couldn't uncompress them on the sun before
putting them on the Mac for transportation because the system kept running
out of disk space). The Apollo felt the same way when I tried to uncompress
the original ftp'ed stuff from UM, which makes me wonder whether I'd
ever get mit-scheme running on the UTS to begin with.
BUT, xscheme transferred over and is presently running on the UTS here
in Naperville. It claims to be consistent with the Reivison↑3 report,
which is fine by me. How bugfree for *regular* schemeing is it? (I,
at the moment, am not interested in its object-oriented extensions.)
Please email all comments, advice, and guidelines to here, or to
att!ihlpn!rre (or rre@ihlpn.uucp).
Thanks!
Roger Espinosa
------------------------------
End of Scheme Digest
********************
∂28-Aug-89 1120 @mc.lcs.mit.edu:hieb@iuvax.cs.indiana.edu multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Aug 89 11:20:41 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AB05289; Mon, 28 Aug 89 14:06:26 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21930;
28 Aug 89 11:21 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Aug 89 11:18:55 EDT
Received: from IUVAX.CS.INDIANA.EDU by mintaka.lcs.mit.edu id aa21840;
28 Aug 89 11:15 EDT
Received: by iuvax.cs.indiana.edu
Date: Mon, 28 Aug 89 10:15:32 -0500
From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: multiple values
Message-Id: <8908281115.aa21840@mintaka.lcs.mit.edu>
I have avoided the mv debate, perhaps hoping nothing would come of it.
I worry whether mvs can be added to Scheme at this point without
"scabbing" them on (a carpenter's idiom, with obvious implications).
But John refuses to give up, and I sense the opposition is weakening.
So I enter at this late stage with a plea to "do it right."
I agree with Will's arguments for a semantics in which
e == (values e)
I also think we must be bold and call it an error whenever more or less than
one value is returned to a single-valued continuation. Otherwise, given the
wording of John's latest version, we are back precisely where Kent wanted us
all along!
From ramsdell@linus.mitre.org Mon Aug 28 06:45:56 1989
...The essence
of the compromise is that we leave unspecified the effect of returning
zero values or more than one value to something other than a receiving
procedure. This means implementations may or may not signal an error
in this case, and both kinds of implementations are considered equally
correct...
...It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator'...
This means, for instance, that
(with-values (lambda () (values 1 'a)) symbol?)
is an error, whereas
(symbol? (values 1 'a))
may be perfectly valid in some implementations (and for that matter,
may return #t).
As I understand it, the substance of Kent's argument all along was that
continuations produced by "with-values" should be distinct
from ordinary continuations, and "values" should be thought of as the
means of interacting with such continuations. On the other hand, the
opposition, with whom I thought myself allied, was arguing that continuations
produced by "with-values" differed only in arity from ordinary continuations.
It seems we are back to two kinds of continuations again.
Am I missing something?
Bob
∂28-Aug-89 1412 ramsdell@linus.mitre.org Re: multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Aug 89 14:12:15 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA06956; Mon, 28 Aug 89 16:06:23 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA08366; Mon, 28 Aug 89 16:07:25 EDT
Posted-Date: Mon, 28 Aug 89 16:00:37 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA00462; Mon, 28 Aug 89 16:00:43 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908282000.AA00462@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: Re: multiple values
In-Reply-To: Your message of Mon, 28 Aug 89 10:15:32 -0500.
<8908281115.aa21840@mintaka.lcs.mit.edu>
Date: Mon, 28 Aug 89 16:00:37 EDT
>> From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
...
>> As I understand it, the substance of Kent's argument all along was that
>> continuations produced by "with-values" should be distinct
>> from ordinary continuations, and "values" should be thought of as the
>> means of interacting with such continuations. On the other hand, the
>> opposition, with whom I thought myself allied, was arguing that continuations
>> produced by "with-values" differed only in arity from ordinary continuations.
>> It seems we are back to two kinds of continuations again.
>>
As I see it, the proposal implies that continuations produced by
WITH-VALUES differ only in arity from ordinary continuations. The
compromise is not to specify the arity of ordinary continuations.
Thus implimentations is which ordinary continuation can only be applied
to only exactly one value are just as valid as implementations which
allow ordinary continuations to be applied to one or more values. I
believe this proposal satisfies your requirements. Please tell me if
you are not convinced.
John
∂28-Aug-89 1619 bawden@arisia.xerox.com Re: multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Aug 89 16:19:44 PDT
Received: from arisia.xerox.com by life.ai.mit.edu (4.1/AI-4.10) id AA09283; Mon, 28 Aug 89 19:00:39 EDT
Received: from roo.parc.Xerox.COM by arisia.xerox.com with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA16474; Mon, 28 Aug 89 15:57:02 -0700
Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA04287; Mon, 28 Aug 89 15:59:33 PDT
Date: Mon, 28 Aug 89 15:58 PDT
From: Alan Bawden <bawden@arisia.xerox.com>
Subject: Re: multiple values
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: <8908282000.AA00462@huxley.mitre.org>
Message-Id: <19890828225827.2.ALAN@MR-BUN.parc.xerox.com>
So is this a permissible implementation of your proposal? It seems to me
that it must be since you only try to specify what happens if other than
one value is returned to WITH-VALUES, and nowhere else.
(define magic-multiple-values-marker (list '* 'multiple 'values '*))
(define (values . vals)
(if (= 1 (length vals))
(car vals)
(cons magic-multiple-values-marker vals)))
(define (with-values thunk receive)
(let ((result (thunk)))
(if (and (pair? result)
(eq? (car result) magic-multiple-values-marker))
(apply receive (cdr result))
(receive result))))
∂28-Aug-89 1955 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers and Pork Rinds
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Aug 89 19:55:08 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA11042; Mon, 28 Aug 89 22:46:00 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22848;
28 Aug 89 12:40 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Aug 89 12:40:40 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa22831;
28 Aug 89 12:37 EDT
Received: from fafnir.think.com by Think.COM; Mon, 28 Aug 89 12:38:53 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 28 Aug 89 12:36:07 EDT
Received: by verdi.think.com; Mon, 28 Aug 89 12:35:45 EDT
Date: Mon, 28 Aug 89 12:35:45 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8908281635.AA09595@verdi.think.com>
To: bawden@arisia.xerox.com
Cc: harrison@s45.csrd.uiuc.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden's message of Sun, 27 Aug 89 14:30 PDT <19890827213042.4.ALAN@MR-BUN.parc.xerox.com>
Subject: Numbers and Pork Rinds
Date: Sun, 27 Aug 89 14:30 PDT
From: Alan Bawden <bawden@arisia.xerox.com>
Floating point numbers can be used as a representation for exact (rational)
numbers as well, if an implementation chooses. But since the set of
rationals represented exactly by floating point is not even approximately
closed under even the most common operations (consider (/ 1 3) or
(+ 1 1000000000000000000000000000000)), this doesn't seem to be a viable
choice.
Actually, an implementation using IEEE arithmetic might find it completely
convenient to have both exact and inexact floats; a result float would be
exact if all inputs are exact AND the IEEE operation(s) reported no inexact
exception. (This is a minor point.)
--Guy
∂28-Aug-89 2212 @mc.lcs.mit.edu:bawden@arisia.xerox.com Numbers and Pork Rinds
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Aug 89 22:12:50 PDT
Received: from MINTAKA.LCS.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB13003; Tue, 29 Aug 89 01:01:19 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24197;
28 Aug 89 14:42 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Aug 89 14:41:11 EDT
Received: from arisia.Xerox.COM by mintaka.lcs.mit.edu id aa24188;
28 Aug 89 14:40 EDT
Received: from roo.parc.Xerox.COM by arisia.xerox.com with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA12805; Mon, 28 Aug 89 11:36:25 -0700
Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA02451; Mon, 28 Aug 89 11:38:57 PDT
Date: Mon, 28 Aug 89 11:37 PDT
From: Alan Bawden <bawden@arisia.xerox.com>
Subject: Numbers and Pork Rinds
To: gls@think.com
Cc: harrison@s45.csrd.uiuc.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8908281635.AA09595@verdi.think.com>
Message-Id: <19890828183753.0.ALAN@MR-BUN.parc.xerox.com>
Date: Mon, 28 Aug 89 12:35:45 EDT
From: gls@Think.COM (Guy Steele)
... an implementation using IEEE arithmetic might find it completely
convenient to have both exact and inexact floats; a result float would be
exact if all inputs are exact AND the IEEE operation(s) reported no inexact
exception....
Quite right. With IEEE giving you this assistance you can even consider
using -only- IEEE floats in your Scheme implementation -- using them for
both exact and inexact numbers. This should give you an adequate range of
exact integers to index vectors and measure the lengths of lists (as well
as a random collection of exact rationals of the form M/(2↑N)). This might
even be a reasonable thing to do if you're trying to do a quick and simple
Scheme implementation. (But if your floating point hardware -doesn't- tell
you about loss of exactness, I can't imagine making such a choice.)
∂29-Aug-89 0050 @mc.lcs.mit.edu,@hp-sde.sde.hp.com:jinx@hpesogg.hp.com multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Aug 89 00:49:50 PDT
Received: from MINTAKA.LCS.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB00296; Tue, 29 Aug 89 03:10:33 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27038;
28 Aug 89 18:22 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Aug 89 18:22:59 EDT
Received: from hp-sde.sde.hp.com by mintaka.lcs.mit.edu id aa27028;
28 Aug 89 18:21 EDT
Received: from hpesogr.cup.hp.com by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA27617; Mon, 28 Aug 89 12:15:30 pdt
Message-Id: <8908281915.AA27617@sde.hp.com>
Received: by hpesogg; Mon, 28 Aug 89 12:14:47 pdt
Date: Mon, 28 Aug 89 12:14:47 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: hieb@iuvax.cs.indiana.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Robert Hieb's message of Mon, 28 Aug 89 10:15:32 -0500 <8908281115.aa21840@mintaka.lcs.mit.edu>
Subject: multiple values
Reply-To: jinx%hpesogg@sde.hp.com
On the other hand, the
opposition, with whom I thought myself allied, was arguing that continuations
produced by "with-values" differed only in arity from ordinary
continuations.
Not quite. There are two issues at stake:
A) (values e) == e
B) Are implicit continuations modelled as
(lambda (value) ...)
or as
(lambda (value . ignore) ...)
I would like to see A hold true, and B adopt the latter solution.
This is impractical politically, so I will grudgingly accept B to be
left unspecified.
Issue A, if rejected, would force two kinds of continuations.
Issue B does not. It just determines (or fails to determine) the
arity of implicit continuations, but they are no different from
"explicit" continuations.
∂29-Aug-89 0517 ramsdell@linus.mitre.org Re: multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Aug 89 05:17:03 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA01881; Tue, 29 Aug 89 07:59:28 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA24071; Tue, 29 Aug 89 08:00:03 EDT
Posted-Date: Tue, 29 Aug 89 07:53:19 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA01279; Tue, 29 Aug 89 07:53:20 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908291153.AA01279@huxley.mitre.org>
To: Alan Bawden <bawden@arisia.xerox.com>
Cc: ramsdell@linus.mitre.org, rrrs-authors@life.ai.mit.edu
Subject: Re: multiple values
In-Reply-To: Your message of Mon, 28 Aug 89 15:58:00 -0700.
<19890828225827.2.ALAN@MR-BUN.parc.xerox.com>
Date: Tue, 29 Aug 89 07:53:19 EDT
>> From: Alan Bawden <bawden@arisia.xerox.com>
...
>> So is this a permissible implementation of your proposal? It seems to me
>> that it must be since you only try to specify what happens if other than
>> one value is returned to WITH-VALUES, and nowhere else.
>>
>> (define magic-multiple-values-marker (list '* 'multiple 'values '*))
>>
>> (define (values . vals)
>> (if (= 1 (length vals))
>> (car vals)
>> (cons magic-multiple-values-marker vals)))
>>
>> (define (with-values thunk receive)
>> (let ((result (thunk)))
>> (if (and (pair? result)
>> (eq? (car result) magic-multiple-values-marker))
>> (apply receive (cdr result))
>> (receive result))))
The above looks to me to be a legal implementation of the proposal.
Alan has shown the ease in which all Scheme implementations can
be modified so as to correctly implement multiple values. Of course,
programmers using quality implementations can expect much better code
to be generated from optimizing compilers.
Leaving the arity of ordinary continuations unspecified is a bit
unsettling, however, I believe it to be the only viable way of
reaching agreement on this subject. I hope this compromise will not
be the last word on the subject of multiple values, but a base on
which we build future agreements. Now is the time to crawl; only
later should we try to walk. Let's wait for Kent's words.
Don't panic,
John
∂29-Aug-89 0657 ramsdell@linus.mitre.org rrrs-authors-request@life.ai.mit.edu is broken.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Aug 89 06:57:27 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02523; Tue, 29 Aug 89 09:29:29 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA24831; Tue, 29 Aug 89 09:30:21 EDT
Posted-Date: Tue, 29 Aug 89 09:23:37 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA01417; Tue, 29 Aug 89 09:23:38 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908291323.AA01417@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: rrrs-authors-request@life.ai.mit.edu is broken.
Date: Tue, 29 Aug 89 09:23:37 EDT
rrrs-authors-request@life.ai.mit.edu is broken.
------- Forwarded Message
Return-Path: MAILER-DAEMON@sde.hp.com
Return-Path: <MAILER-DAEMON@sde.hp.com>
Received: from hp-sde.sde.hp.com by linus.MITRE.ORG (5.59/RCF-3S)
id AA24792; Tue, 29 Aug 89 09:28:45 EDT
Posted-Date: Tue, 29 Aug 89 09:20:58 EDT
Received: from hp-ses.sde.hp.com by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA23661; Tue, 29 Aug 89 06:27:25 pdt
Received: from sde.hp.com by hp-ses.sde.hp.com with SMTP
(15.7/SES42.42) id AA09554; Tue, 29 Aug 89 06:27:21 pdt
Date: Tue, 29 Aug 89 09:20:58 EDT
From: Mail Delivery Subsystem <MAILER-DAEMON@sde.hp.com>
Subject: Returned mail: unknown mailer error 101
Message-Id: <8908291327.AA09554@hp-ses.sde.hp.com>
To: <ramsdell@linus.MITRE.ORG>
----- Transcript of session follows -----
bad system name: hpesogg
uux failed. code 101
554 <jinx@hpesogg>... unknown mailer error 101
----- Unsent message follows -----
Received: from sde.hp.com by hp-ses.sde.hp.com with SMTP
(15.7/SES42.42) id AA09550; Tue, 29 Aug 89 06:27:21 pdt
Return-Path: <ramsdell@linus.mitre.org>
Received: from life.ai.mit.edu by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA23656; Tue, 29 Aug 89 06:27:15 pdt
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02511; Tue, 29 Aug 89 09:27:13 EDT
Received: from life.ai.mit.edu (life.ai.mit.edu) by zurich.ai.mit.edu; Tue, 29 Aug 89 09:24:00 edt
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02508; Tue, 29 Aug 89 09:26:39 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA24785; Tue, 29 Aug 89 09:27:42 EDT
Posted-Date: Tue, 29 Aug 89 09:20:58 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA01407; Tue, 29 Aug 89 09:20:59 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908291320.AA01407@huxley.mitre.org>
To: rrrs-authors-request@life.ai.mit.edu
Subject: rrrs-authors-request test.
Date: Tue, 29 Aug 89 09:20:58 EDT
Just a test.
------- End of Forwarded Message
∂29-Aug-89 0732 @mc.lcs.mit.edu,@hp-sde.sde.hp.com:jinx@hpesogg.hp.com Numbers and Pork Rinds
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Aug 89 07:31:37 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02912; Tue, 29 Aug 89 10:17:02 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04537;
29 Aug 89 3:55 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Aug 89 03:55:57 EDT
Received: from hp-sde.sde.hp.com by mintaka.lcs.mit.edu id aa04514;
29 Aug 89 3:54 EDT
Received: from hpesogr.cup.hp.com by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA13335; Tue, 29 Aug 89 00:18:54 pdt
Message-Id: <8908290718.AA13335@sde.hp.com>
Received: by hpesogg; Tue, 29 Aug 89 00:16:49 pdt
Date: Tue, 29 Aug 89 00:16:49 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: gls@think.com
Cc: bawden@arisia.xerox.com, harrison@s45.csrd.uiuc.edu,
rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Guy Steele's message of Mon, 28 Aug 89 12:35:45 EDT <8908281635.AA09595@verdi.think.com>
Subject: Numbers and Pork Rinds
Reply-To: jinx%hpesogg@sde.hp.com
Actually, an implementation using IEEE arithmetic might find it completely
convenient to have both exact and inexact floats; a result float would be
exact if all inputs are exact AND the IEEE operation(s) reported no inexact
exception. (This is a minor point.)
This is where the notion of inexactness in fact came from. The
original idea was to have an orthogonal exactness bit for each
representation which the implementation would maintain correctly.
∂29-Aug-89 0838 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #188
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Aug 89 08:38:18 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA03326; Tue, 29 Aug 89 10:58:53 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01300;
26 Aug 89 17:11 EDT
Date: 26 AUG 89 16:38:46 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Subject: Scheme Digest #188
To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id: <8908261711.aa01300@mintaka.lcs.mit.edu>
Scheme Digest #188 26 AUG 89 16:38:46 EDT
Today's Topics:
Is there a version of xscheme later than 0.16?
OOPS system for Scheme - where?
X Scheme availability
----------------------------------------------------------------------
Date: 24 Aug 89 16:37:55 GMT
From: "Luiz H. deFigueiredo" <att!watmath!maytag!aries5!lhf@bloom-beacon.mit.edu>
Subject: Is there a version of xscheme later than 0.16?
Message-Id: <413@maytag.waterloo.edu>
Does anyone know about this?
Dave Betz, maybe?
-------------------------------------------------------------------------------
Luiz Henrique de Figueiredo internet: lhf@aries5.waterloo.edu
Computer Systems Group bitnet: lhf@watcsg
University of Waterloo (possible domains are waterloo.edu and uwaterloo.ca)
-------------------------------------------------------------------------------
------------------------------
Date: 25 Aug 89 17:32:22 GMT
From: Mark Biggers <rti!xyzzy!dg-rtp!biggers@mcnc.org>
Subject: OOPS system for Scheme - where?
Message-Id: <BIGGERS.89Aug25133222@zippy.dg-rtp.dg.com>
Howdy,
I would be very interested in public-domain or freely available
sources for an object system for Scheme, such as SCOOPS, or some
analog of CLOS for Scheme. Pointers, please?
thanks much,
mark
(news mail header is bogus; mail addresses below...)
--
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
biggers@dg-rtp.dg.com USMail: Data General
OR: rti!dg-rtp!biggers 62 Alexander Drive
Research Triangle Park, NC 27709
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
------------------------------
Date: 25 Aug 89 03:04:06 GMT
From: jdm <hodge!jdm@uunet.uu.net>
Subject: Re: X Scheme availability
Message-Id: <21650@hodge.UUCP>
>
> Is there a newer version? I'd like a copy too.
>
Not to long ago I downloaded Xscheme 0.17 from the Video 7 BBS (yes,
the VGA board people) at 415-656-0503 (12|2400,8,N,1).
--
"I'm an anthropologist, not a computer systems architect, damit!"
jdm@hodge.cts.com [uunet zardoz crash]!hodge!jdm
James D. Murray, Ethnounixologist TEL: (714) 998-7750 Ext. 129
Hodge Computer Research Corporation FAX: (714) 921-8038
1588 North Batavia Street
Orange, California 92667 USA
------------------------------
End of Scheme Digest
********************
∂29-Aug-89 0915 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #190
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Aug 89 09:15:12 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02557; Tue, 29 Aug 89 09:35:50 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01591;
29 Aug 89 0:09 EDT
Date: 29 AUG 89 00:07:47 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Subject: Scheme Digest #190
To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id: <8908290009.aa01591@mintaka.lcs.mit.edu>
Scheme Digest #190 29 AUG 89 00:07:47 EDT
Today's Topics:
Scheme Digest #169
----------------------------------------------------------------------
Date: Mon, 28 Aug 89 21:08 CST
From: RKIRCHNE@carleton.edu
Subject: RE: Scheme Digest #169
Message-ID: <8908282205.aa29915@mintaka.lcs.mit.edu>
This is the last Scheme Digest I have. Our network has been down
for a couple of weeks. Could you have my name reactivated and send me
Digests 170- ? Thanks. Roger Kirchner
------------------------------
End of Scheme Digest
********************
∂29-Aug-89 1316 mkatz@sesame.stanford.edu Kent, please bless this multiple values proposal.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Aug 89 13:13:27 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA06912; Tue, 29 Aug 89 15:52:59 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00670; Tue, 29 Aug 89 12:51:36 PDT
Date: Tue, 29 Aug 89 12:51:36 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8908291951.AA00670@sesame.Stanford.EDU>
To: ramsdell@linus.mitre.org
Cc: dyb@iuvax.cs.indiana.edu, rrrs-authors@life.ai.mit.edu,
ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Mon, 28 Aug 89 07:30:00 EDT <8908281130.AA16873@huxley.mitre.org>
Subject: Kent, please bless this multiple values proposal.
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Posted-Date: Mon, 28 Aug 89 07:30:00 EDT
From: ramsdell@linus.mitre.org
Date: Mon, 28 Aug 89 07:30:00 EDT
I believe I have a multiple values proposal acceptable to all.
(values obj ...) essential procedure
...
The effect of returning zero values or more than one value to something
other than a receiving procedure is unspecified.
I believe that the sentence above leaves things a little too unspecified. In
particular, I believe that it is important that in the following code CONT
accept exactly two values.
(with-values
(call-with-current-continuation
(lambda (c)
(set! cont c)
(values 1 2)))
cons)
Similarly, any continuation captured with CALL-WITH-CURRENT-CONTINUATION which
tail recurses into the first argument position of WITH-VALUES should require
and exact arity match with the receiver.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂29-Aug-89 1920 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Programmer-defined data types, version 2
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Aug 89 19:20:05 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA10759; Tue, 29 Aug 89 22:01:18 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09107;
29 Aug 89 21:54 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Aug 89 21:54:58 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09063;
29 Aug 89 21:52 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA10725; Tue, 29 Aug 89 21:52:27 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Tue, 29 Aug 89 21:49:08 edt
Received: from Semillon.ms by ArpaGateway.ms ; 29 AUG 89 18:47:15 PDT
Date: Tue, 29 Aug 89 18:29:19 PDT
From: Pavel.pa@xerox.com
Subject: Programmer-defined data types, version 2
To: RRRS-Authors@zurich.ai.mit.edu
Cc: Pavel.pa@xerox.com
Message-Id: <890829-184715-4408@Xerox>
Several people either proposed or supported a proposal that
RECORD-CONSTRUCTOR take a second argument, being a list of the slots
initialized by the new constructor, in the order of the actual arguments to
the constructor. I support this change; it is reflected in the new version
of the proposal below.
In mail to the BASH list, Morry asked that this new second argument be
optional, defaulting to the relatively common case of all slots, in the
order specified in the call to MAKE-RECORD-TYPE. I think I agree with that
and can appreciate his dissatisfaction with the prospect of having to
repeat the entire list of names again. This modification of the above
proposal is also reflected below.
Kent Pitman (I wish others would be more specific when they quote ``Kent''
on this list; sometimes it's non-trivial to determine whether they're
talking about the ``Pitman'' or ``Dybvig'' flavor...) made a number of
suggestions concerning the default values of slots not initialized by a
constructor. This discussion extended into what amounted to an
active-value facility, with hooks provided for notification when slots are
read or written. My response is to say that it certainly seems as if such
facilities might be useful, but they are definitely beyond the scope of
this proposal. The intent here is simply to provide the raw facilities for
user-defined data types. Everything Kent suggests can be written in terms
of what's provided here and perhaps placed in the library; if they receive
widespread approval, perhaps we could later consider them for inclusion in
the language.
In a similar vein, Ziggy would like constructors to follow what amounts to
a Common Lisp keyword-style calling protocol, in which each slot value is
preceded in the argument list by the name of the slot. This would be
inconsistent with every other procedure currently in Scheme (CONS comes to
mind as the best example), so I am reluctant to add it here. Again, such a
facility could be implemented for the library.
Several people reported varying levels of nausea resulting from my use of
the term ``slot'' where, for example, ``field'' might have been less
traumatic. I have made the stomach-settling change in the proposal below.
I made a note that ``the type-name argument to MAKE-RECORD-TYPE is
constrained to be a string in order to allow experimentation with
interesting semantics for other kinds of values there. One possibility
raised in the discussion in 1988 was some kind of a `handler' procedure, as
in T objects.'' In reaction, Bawden commented, ``Even if someday you can
pass a ``handler'' to MAKE-RECORD-TYPE, mightn't you -also- want to pass a
type-name? I don't see how the two are exclusive.'' I believe this is
handled in T by having the handler deal with an operation that provides the
type-name. Thus, in such a system, passing a string would be equivalent to
passing a simple handler that only dealt with the fetch-type-name
operation. In any case, I don't have a strong opinion about this; it does
not appear that Alan does either, so I've left this part of the proposal
unchanged.
Alan was the only person to comment on the semantics of EQUAL? when applied
to records of the same type, expressing the opinion that EQUAL? should
behave like EQV? in such cases. I take others' silence on the point as
agreement and have so modified the proposal.
Norman would like to see all ``abstraction-breaking'' procedures so
identified in their description. I think that this classification could
well be a matter of opinion on which some authors may disagree. For the
time being, therefore, I have not followed up on this suggestion. I
welcome comments.
Norman expressed the only opinion on whether or not a RECORD-COPIER
procedure should exist; Norman feels that it should not, being just one of
several possible operations generic to records. I tend to agree and so
have removed the issue from the proposal.
Ziggy asked why, in the desciption of RECORD-TYPE-SLOT-NAMES, the returned
value is constrained to be EQUAL? to the list of names given to
MAKE-RECORD-TYPE. This is necessary in order to use RECORD-CONSTRUCTOR
properly; it must be possible to discover the order of arguments to
constructors. Of course, this is no longer necessary, since the given list
can now be passed as the second argument to RECORD-CONSTRUCTOR. I have
therefore rewritten the restriction, below, to imply only set-equality of
the two lists.
I think that this covers all of the responses I've received thus far. I'm
sure I'll hear about it if that's not the case... Here is the new version
of the proposal.
=====================
We propose adding the following procedures to Scheme:
(MAKE-RECORD-TYPE type-name field-names)
Returns a ``record-type descriptor'', a value representing a new data type,
disjoint from all others. The type-name argument must be a string, but is
only used for debugging purposes (such as the printed representation of a
record of the new type). The field-names argument is a list of symbols
naming the ``fields'' of a record of the new type. It is an error if the
list contains any duplicates.
(RECORD-CONSTRUCTOR rtd [field-names])
Returns a procedure for constructing new members of the type represented by
rtd. The returned procedure accepts exactly as many arguments as there are
symbols in the given list, field-names; these are used, in order, as the
initial values of those fields in a new record, which is returned by the
constructor procedure. The values of any fields not named in that list are
unspecified. The field-names argument defaults to the list of field-names
in the call to MAKE-RECORD-TYPE that created the type represented by rtd;
if the field-names argument is provided, it is an error if it contains any
duplicates or any symbols not in the default list.
(RECORD-PREDICATE rtd)
Returns a procedure for testing membership in the type represented by rtd.
The returned procedure accepts exactly one argument and returns a true
value if the argument is a member of the indicated record type; it returns
a false value otherwise.
(RECORD-ACCESSOR rtd field-name)
Returns a procedure for reading the value of a particular field of a member
of the type represented by rtd. The returned procedure accepts exactly one
argument which must be a record of the appropriate type; it returns the
current value of the field named by the symbol field-name in that record.
The symbol field-name must be a member of the list of field-names in the
call to MAKE-RECORD-TYPE that created the type represented by rtd.
(RECORD-UPDATER rtd field-name)
Returns a procedure for writing the value of a particular field of a member
of the type represented by rtd. The returned procedure accepts exactly two
arguments: a record of the appropriate type and an arbitrary Scheme value;
it modifies the field named by the symbol field-name in that record to
contain the given value. The returned value of the updater procedure is
unspecified. The symbol field-name must be a member of the list of
field-names in the call to MAKE-RECORD-TYPE that created the type
represented by rtd.
(RECORD? obj)
Returns a true value if obj is a record of any type and a false value
otherwise.
(RECORD-TYPE-DESCRIPTOR record)
Returns a record-type descriptor representing the type of the given record.
That is, for example, if the returned descriptor were passed to
RECORD-PREDICATE, the resulting predicate would return a true value when
passed the given record. Note that it is not necessarily the case that the
returned descriptor is the one that was passed to RECORD-CONSTRUCTOR in the
call that created the constructor procedure that created the given record.
(RECORD-TYPE-NAME rtd)
Returns the type-name associated with the type represented by rtd. The
returned value is EQV? to the type-name argument given in the call to
MAKE-RECORD-TYPE that created the type represented by rtd.
(RECORD-TYPE-FIELD-NAMES rtd)
Returns a list of the symbols naming the fields in members of the type
represented by rtd. The returned value contains precisely the set of
symbols in the field-names argument given in the call to MAKE-RECORD-TYPE
that created the type represented by rtd.
=====================
Notes on the proposal
=====================
-- The procedure RECORD? is necessary to allow reliable use of the
procedure RECORD-TYPE-DESCRIPTOR.
-- The type-name argument to MAKE-RECORD-TYPE is constrained to be a string
in order to allow experimentation with interesting semantics for other
kinds of values there. One possibility raised in the discussion in 1988
was some kind of a ``handler'' procedure, as in T objects.
-- We do not propose any general macro for the definition of record types.
The feeling is that this is not easy to do in a way that is both elegant
and sufficiently flexible. Once we have macros, the primitives above
should be sufficient for portable experimentation.
-- The issues of subtyping and inheritance, print methods, and integration
with modules and/or
environments (e.g. Pascal's WITH construct) have been purposely avoided in
order to achieve more rapid consensus. Designs for adding single
inheritance appeared in the discussion in 1988.
-- A case can be made that constructor procedures should take no arguments
and leave all fields in new records uninitialized. There appear to be
advantages to both points of view.
-- EQ? and EQV? treat records in the same way as they do pairs, vectors,
and strings. EQUAL? is equivalent to EQV? on records.
Pavel
∂30-Aug-89 0021 Pavel.pa@xerox.com Multiple values
Received: from life.ai.mit.edu ([128.52.32.80]) by SAIL.Stanford.EDU with TCP; 30 Aug 89 00:21:49 PDT
Received: from Xerox.COM by life.ai.mit.edu (4.1/AI-4.10) id AA00287; Wed, 30 Aug 89 03:05:04 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 29 AUG 89 19:08:56 PDT
Date: Tue, 29 Aug 89 19:10:26 PDT
From: Pavel.pa@xerox.com
Subject: Multiple values
To: RRRS-Authors@life.ai.mit.edu
Cc: Pavel.pa@xerox.com
Message-Id: <890829-190856-4440@Xerox>
I essentially support the current multiple-values proposal, but I have a
few comments and suggested clarifications.
-- At BASH, we decided that what has been called WITH-VALUES would be
better named CALL-WITH-VALUES, to be consistent with CALL-WITH-INPUT-FILE.
I still agree with this, but wouldn't hold up progress if others were
strongly opposed to this name.
-- I am unhappy with the current description of VALUES, in particular with
the special casing of the single-argument case. Why not simply say that
VALUES returns all of its arguments? Alternatively, could we simply give
the simple implementation of VALUES in terms of CALL/CC?
(define values args
(call-with-current-continuation
(lambda (k)
(apply k args))))
This seems a lot more clear than what's there now.
-- I am similarly unhappy with the way in which the arity of continuations
is described. Allow me to suggest the following:
==========
There are six contexts in which continuations can be captured in Scheme:
* the operator position of a procedure call,
* an operand position of a procedure call,
* the test position of a conditional,
* the ``right-hand side'' of an assignment,
* any but the last expression in the body of a lambda expression, and
* the application of the first argument to CALL-WITH-VALUES.
The first four contexts are normally thought of as accepting exactly one
value; the effect of passing extra values to such continuations is
unspecified.
The fifth context above ignores any values it receives and so accepts any
number of values, including zero.
In the final context above, the given values are supplied as arguments to
the second argument in the call to CALL-WITH-VALUES. Correspondingly, the
arity of the continuation is precisely that of the second argument.
==========
The point of the above is to clarify what we intend. In particular, I
wanted to make it clear exactly what was unspecified and to completely
specify the arity of the ``for-effect'' context. I also believe that this
description may satisfy Morry's concern about the arity of continuations
created by CALL-WITH-VALUES.
-- Next, I don't think I agree with John that Alan's cheapo implementation
of multiple values is correct. In particular, I think that the
implementation of VALUES given ought to work; that is, I think that I
should be able to make multiple-argument calls on continuations when I know
their arity. In Alan's implementation, all continuations take exactly one
argument.
As an example of why I think this is important, consider using CALL/CC for
an escape function from a loop. When I want to escape returning multiple
values, I have to jump through hoops in Alan's implementation, whereas I
can do the obvious thing in a correct one.
-- Finally, as a side note, perhaps we could take this opportunity to
further unspecify the returned values of SET! expressions and the various
side-effecting primitives. As it is, we say that they return a single
unspecified value. Could we go a bit further and say that they return an
unspecified number of unspecified values? I'd like to be able to implement
them as returning zero values in Scheme Xerox.
Pavel
∂30-Aug-89 0522 ramsdell@linus.mitre.org multiple values and call/cc.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Aug 89 05:22:15 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA01428; Wed, 30 Aug 89 08:00:26 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA03252; Wed, 30 Aug 89 08:01:18 EDT
Posted-Date: Wed, 30 Aug 89 07:54:33 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA02579; Wed, 30 Aug 89 07:54:35 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908301154.AA02579@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org, guttman@linus.mitre.org
Subject: multiple values and call/cc.
In-Reply-To: Your message of Tue, 29 Aug 89 12:51:36 -0700.
<8908291951.AA00670@sesame.Stanford.EDU>
Date: Wed, 30 Aug 89 07:54:33 EDT
>> From: mkatz@sesame.stanford.edu (Morris Katz)
...
>> (with-values
>> (call-with-current-continuation
>> (lambda (c)
>> (set! cont c)
>> (values 1 2)))
>> cons)
I do not understand your example. It seems to me the generator does
not evaluate to a procedure applicable to zero arguments. Independent
of the example, I think I get your point. What the proposal should
say is that values could be defined as:
(define (values . args)
(call-with-current-continuation
(lambda (cont) (apply cont args))))
and with-values creates a continuation with arity exactly matching the
arity of the receiver. The arity of ordinary continuations is to be
left unspecified. So let me try one more time.
--------------------------------
(values obj ...) essential procedure
Applies the current continuation to 0 or more values. It is used to
return multiple values (see with-values). Values could be defined as:
(define (values . args)
(call-with-current-continuation
(lambda (cont) (apply cont args))))
(with-values generator receiver) essential procedure
Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with no arguments. It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator' or if 'generator' cannot be called with zero arguments.
Within procedure 'generator', the initial escape procedure returned by
call-with-current-continuation is 'receiver'.
(with-values
(lambda ()
(values 1 2))
cons) => (1 . 2)
(with-values
(lambda ()
(call-with-current-continuation
(lambda (k)
(k 1 2))
cons) => (1 . 2)
-------------------------------
Notice that the discussion of the arity of ordinary continuations must
be moved to the section describing call-with-current-continuation. I
have yet to draft any text, but I have not forgotten the problem.
John
∂30-Aug-89 0528 ramsdell@linus.mitre.org Re: Multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Aug 89 05:27:45 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA01456; Wed, 30 Aug 89 08:09:12 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA03295; Wed, 30 Aug 89 08:10:06 EDT
Posted-Date: Wed, 30 Aug 89 08:03:21 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA02590; Wed, 30 Aug 89 08:03:23 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908301203.AA02590@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: Re: Multiple values
In-Reply-To: Your message of Tue, 29 Aug 89 19:10:26 -0700.
<890829-190856-4440@Xerox>
Date: Wed, 30 Aug 89 08:03:21 EDT
>> From: Pavel.pa@xerox.com
...
>> -- At BASH, we decided that what has been called WITH-VALUES would be
>> better named CALL-WITH-VALUES, to be consistent with CALL-WITH-INPUT-FILE.
>> I still agree with this, but wouldn't hold up progress if others were
>> strongly opposed to this name.
I am quite willing to entertain suggestions for alternative names, but
how about waiting until after we get agreement on the basic proposal?
John
PS. Sorry about the unbalanced parens in my last note. The example
should be:
(with-values
(lambda ()
(call-with-current-continuation
(lambda (k)
(k 1 2))))
cons) => (1 . 2)
∂30-Aug-89 1205 katz@polya.stanford.edu Multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Aug 89 12:05:34 PDT
Received: from Polya.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA05125; Wed, 30 Aug 89 14:39:29 EDT
Received: by Polya.Stanford.EDU (5.61/25-eef) id AA19695; Wed, 30 Aug 89 11:38:49 -0700
Date: Wed, 30 Aug 89 11:38:49 -0700
From: Morris J. Katz <katz@polya.stanford.edu>
Message-Id: <8908301838.AA19695@Polya.Stanford.EDU>
To: Pavel.pa@xerox.com
Cc: RRRS-Authors@life.ai.mit.edu, Pavel.pa@xerox.com
In-Reply-To: Pavel.pa@xerox.com's message of Tue, 29 Aug 89 19:10:26 PDT <890829-190856-4440@Xerox>
Subject: Multiple values
Date: Tue, 29 Aug 89 19:10:26 PDT
From: Pavel.pa@xerox.com
-- Finally, as a side note, perhaps we could take this opportunity to
further unspecify the returned values of SET! expressions and the various
side-effecting primitives. As it is, we say that they return a single
unspecified value. Could we go a bit further and say that they return an
unspecified number of unspecified values? I'd like to be able to implement
them as returning zero values in Scheme Xerox.
I agree. This is one of the cases that Mike and I had in mind when we
stated in our original proposal that we would need to discuss the
arity of all existing Scheme procedures.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂30-Aug-89 1310 ramsdell@linus.mitre.org Revised multiple values and call/cc.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Aug 89 13:09:59 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA05916; Wed, 30 Aug 89 15:45:04 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA13398; Wed, 30 Aug 89 15:45:53 EDT
Posted-Date: Wed, 30 Aug 89 15:39:08 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA02909; Wed, 30 Aug 89 15:39:10 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908301939.AA02909@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Revised multiple values and call/cc.
In-Reply-To: Your message of Wed, 30 Aug 89 07:54:33 -0400.
<8908301154.AA02579@huxley.mitre.org>
Date: Wed, 30 Aug 89 15:39:08 EDT
Let me revise the proposal by substituting
Within procedure 'generator', the initial escape procedure returned
by call-with-current-continuation is like 'receiver' except that
this escape procedure's continuation is the one that was in effect
when the evaluation of the with-values expression began (see
call-with-current-continuation).
for
Within procedure 'generator', the initial escape procedure returned
by call-with-current-continuation is 'receiver'.
--------------------------------
(values obj ...) essential procedure
Applies the current continuation to 0 or more values. It is used to
return multiple values (see with-values). Values could be defined as:
(define (values . args)
(call-with-current-continuation
(lambda (cont) (apply cont args))))
(with-values generator receiver) essential procedure
Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with no arguments. It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator' or if 'generator' cannot be called with zero arguments.
Within procedure 'generator', the initial escape procedure returned by
call-with-current-continuation is like 'receiver' except that this
escape procedure's continuation is the one that was in effect when
the evaluation of the with-values expression began (see
call-with-current-continuation).
(with-values
(lambda ()
(values 1 2))
cons) => (1 . 2)
(with-values
(lambda ()
(call-with-current-continuation
(lambda (k)
(k 1 2))))
cons) => (1 . 2)
-------------------------------
Notice that the discussion of the arity of ordinary continuations must
be moved to the section describing call-with-current-continuation. I
have yet to draft any text, but I have not forgotten the problem.
John
∂30-Aug-89 1522 dyb@iuvax.cs.indiana.edu Re: Multiple values for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Aug 89 15:21:59 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07362; Wed, 30 Aug 89 17:55:49 EDT
Message-Id: <8908302155.AA07362@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Wed, 30 Aug 89 16:56:19 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: rrrs-authors@life.ai.mit.edu
Subject: Re: Multiple values for R4RS
> Date: Fri, 25 Aug 89 21:18:22 PDT
> From: will@cs.uoregon.edu
> Subject: Multiple values for R4RS
>
> The reason I don't like a semantics in which (VALUES E) is not required
> to be the same as E doesn't have anything to do with whether I can
> implement the semantics I like (I can, regardless). It has a little bit
> to do with whether I can write certain portable programs (see example
> below), but not much. It mainly has to do with the complexity of Scheme
> considered as a programming language independent of its implementations.
>
> The only way that I can see to understand or explain a semantics in
> which (VALUES E) is not required to be the same as E is to postulate
> an entirely new kind of object whose sole purpose is to communicate
> between VALUES and receivers of multiple values. I then have to say
> that the effect is undefined (or an error) if this new kind of object
> ever gets passed to an ordinary continuation, procedure, or special
> form (e.g. IF). That's a considerable amount of intellectual overhead
> if the only reason for it is to allow some particular implementation
> "to signal an error whenever someone attempts to return (VALUES ...)
> to a context where multiple values aren't expected, or something other
> than (VALUES ...) to a context expecting multiple values".
I don't see it. If you want to build "values" and "with-values" into
the semantics, where "(values e)" is distinct from "e", you will have
to use a tagged sequence instead of a sequence, add a few lines total
for "values" and "with-values", make a slight modification to "send",
and make another slight modification to "single". Am I missing
something?
> Here's an example of a potentially useful procedure that would be
> less useful if (VALUES E) is not required to be the same as E:
>
> ; Given two procedures F and G, COMPOSE returns a procedure that
> ; acts as the composition of F and G. The arguments to F consist
> ; of all the values returned by G.
This is a good example, one I hadn't considered.
> I have given two reasons in this message, both of which are independent
> of the truncation feature. I'm curious to know what you think of them,
> and even more curious to know why signalling that error is so important
> to you.
My reasoning is based on the assumptions that (a) it is likely that a
program that doesn't work if "(values e)" is distinct from "e" was
probably written that way by mistake, and (b) any program written with
the assumption that "(values e)" was equivalent to "e" could be easily
rewritten to one that does not assume that "(values e)" is equivalent
to "e". Clearly, assumption (b) was incorrect.
I now see that there is some value in requiring "(values e)" to be the
same as "e", even in the absense of the infamous "truncation" feature.
There is also some value in requiring (or allowing) "(values e)" to be
distinct from "e". I see the latter as simpler, not more eomplex, both
in terms of the semantics and in terms of the implementation. However,
as I said at Snowbird, I am willing to defer to the judgement of the
majority on this issue.
Kent
∂30-Aug-89 1802 @mc.lcs.mit.edu:hieb@iuvax.cs.indiana.edu mv continuations
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Aug 89 18:01:56 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00352; Wed, 30 Aug 89 20:54:31 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17977;
30 Aug 89 14:51 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Aug 89 14:39:34 EDT
Received: from IUVAX.CS.INDIANA.EDU by mintaka.lcs.mit.edu id aa17566;
30 Aug 89 14:24 EDT
Received: by iuvax.cs.indiana.edu
Date: Wed, 30 Aug 89 13:13:48 -0500
From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: mv continuations
Message-Id: <8908301424.aa17566@mintaka.lcs.mit.edu>
From ramsdell@linus.mitre.org Wed Aug 30 07:09:54 1989
...I think I get your point. What the proposal should
say is that values could be defined as:
(define (values . args)
(call-with-current-continuation
(lambda (cont) (apply cont args))))
Fine.
and with-values creates a continuation with arity exactly matching the
arity of the receiver...
Not so fine. I think we should avoid saying anything about the "arity" of
such continuations. The proposal goes on to say:
Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with no arguments. It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator' or if 'generator' cannot be called with zero arguments.
Here it seems that it is the procedure call that is source of any arity
errors, not the continuation itself. It is quite reasonable for the
continuation itself to be of indefinite arity; in fact, that is way
the current R*S semantics has it, and the way an implementation
might handle it.
A similar confusion is also apparent in the following:
Within procedure 'generator', the initial escape procedure returned by
call-with-current-continuation is 'receiver'.
"receiver" just evaluates to a value; it may or may not be an "escape
procedure." The continuation created by "with-values" for the invocation
of "generator" is not the same as the value returned by "receiver."
The continuation is rather the application of the value returned by
"receiver" to the values returned by "generator" plus the continuation
of the call to "with-values."
∂30-Aug-89 1833 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: Programmer-defined data types, version 2
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Aug 89 18:33:32 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00691; Wed, 30 Aug 89 21:22:44 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18099;
30 Aug 89 14:55 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Aug 89 14:45:40 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa17724;
30 Aug 89 14:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA05117; Wed, 30 Aug 89 14:37:34 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Wed, 30 Aug 89 14:34:11 edt
Received: from Semillon.ms by ArpaGateway.ms ; 30 AUG 89 10:28:43 PDT
Date: Wed, 30 Aug 89 10:20:29 PDT
From: Pavel.pa@xerox.com
Subject: Re: Programmer-defined data types, version 2
In-Reply-To: <8908301634.AA00973@hobbes.ads.com>
To: RRRS-Authors@zurich.ai.mit.edu
Message-Id: <890830-102843-5610@Xerox>
Concerning Andy's two points.
External representation: This is not as easy to solve as you might
initially think. Note that the ``type-name'' has no semantic import
whatsoever; in particular, it is not guaranteed to be different from all
other type-name's in the system. Record-type descriptors are
(purposefully) entirely anonymous values; thus, there is no way to map a
type-name back into a descriptor and so no way for the reader to deal with
a syntax of the form #{ "TYPENAME" ... }.
Adding fields to records or record-types dynamically: This seems to me an
interesting facility that could be built on top of the primitives
described. I'm very concerned that we not hair up this very simple
functionality with extras that can be built on top of what's already here;
such extras should be added to the library and experimented with by the
community. The records facility is not intended to be an object-oriented
facility; it captures exactly one simple notion: tuples with a fixed set of
named components.
Pavel
∂30-Aug-89 2012 @mc.lcs.mit.edu,@life.ai.mit.edu:andy@ads.com Re: Programmer-defined data types, version 2
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Aug 89 20:11:53 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02068; Wed, 30 Aug 89 22:58:50 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18107;
30 Aug 89 14:55 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Aug 89 14:45:52 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa17749;
30 Aug 89 14:41 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA05133; Wed, 30 Aug 89 14:40:59 EDT
Received: from hobbes.ads.com ([128.229.1.19]) by zurich.ai.mit.edu; Wed, 30 Aug 89 14:37:44 edt
Received: by hobbes.ads.com (5.59/1.11)
id AA00973; Wed, 30 Aug 89 09:34:48 PDT
Date: Wed, 30 Aug 89 09:34:48 PDT
From: Andy Cromarty <andy@ads.com>
Message-Id: <8908301634.AA00973@hobbes.ads.com>
To: RRRS-Authors@zurich.ai.mit.edu
Subject: Re: Programmer-defined data types, version 2
Cc: Pavel.pa@xerox.com, andy%hobbes@ads.com
I like Pavel's record operators proposal.
Reading it, I had two thoughts about additional capabilities that
we may wish to consider. (I feel no religious fervor regarding
this two proposals; I'm simply suggesting them for joint consideration.)
1. It would be useful to have an "external representation" for records
analogous to those available for lists and vectors:
lists: `( ... )
vectors: '#( ...)
strings: " ... "
records: ???
This seems especially valuable since it takes a lot of legwork to
create a single record instance compared to the cost of typing,
say, '(a b c), or for that matter (list 'a 'b 'c). An external
representation could be helpful where the programmer wishes to
initialize variables within a lexical closure and as a means of
portably transferring record instances between different Scheme
images or implementations without having to generate Scheme source
code on the fly to reproduce those instances. (I assume Pavel's
note about not proposing "any general macro for definition of
record types" was not intended to refer to external representations
of record instances.)
I realize that this risks reopening the debate about reserving
everyone's favorite characters, but as a strawman, we might use
something like '#{ "TYPENAME" ... }, with appropriately fleshing out
of details.
2. As I read Pavel's proposal, records are polymorphic but of fixed
extent. But there are cases where it is useful to be able to extend
set of fields of a record dynamically. For example, we might
wish to use records to implement an "object-oriented" sublanguage
and use a separate field for each method; fixed-extent records
would not allow extension of the set of methods once a type had
been declared. (Of course, there are ways around this, e.g. naming
one field "methods" and holding some dynamic-extent data structure
like a list in that field, but this seems a little like the
observation that "you can implement LISP lists using FORTRAN
arrays"---true but not very interesting.) Fixed extent does feel
like a little bit of a limitation of the potential of records as
a data structure. Perhaps we should consider a (non-essential?)
procedure that extends the set of fields of a record type
(non-essential because it could complicate things and slow performance
for some implementation techniques).
asc
∂30-Aug-89 2042 @mc.lcs.mit.edu,@life.ai.mit.edu:katz@polya.stanford.edu Programmer-defined data types, version 2
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Aug 89 20:42:34 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02365; Wed, 30 Aug 89 23:30:16 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18439;
30 Aug 89 15:08 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Aug 89 15:08:28 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa18283;
30 Aug 89 15:03 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA05518; Wed, 30 Aug 89 15:02:56 EDT
Received: from Polya.Stanford.EDU (polya.stanford.edu) by zurich.ai.mit.edu; Wed, 30 Aug 89 14:59:43 edt
Received: by Polya.Stanford.EDU (5.61/25-eef) id AA20609; Wed, 30 Aug 89 12:02:13 -0700
Date: Wed, 30 Aug 89 12:02:13 -0700
From: "Morris J. Katz" <katz@polya.stanford.edu>
Message-Id: <8908301902.AA20609@Polya.Stanford.EDU>
To: rRRS-Authors@zurich.ai.mit.edu
Subject: Programmer-defined data types, version 2
In-Reply-To: Pavel.pa@xerox.com's message of Tue, 29 Aug 89 18:29:19 PDT <890829-184715-4408@Xerox>
For aesthetic reasons I would prefer to see
(MAKE-RECORD-TYPE type-name . field-names)
rather than
(MAKE-RECORD-TYPE type-name field-names)
as the for for MAKE-RECORD-TYPE.
To me
(make-record-type car 'num-doors 'engine-size)
is a lot more elegant than
(make-record-type car '(num-doors engine-size)).
How do others feel?
The only problem I see with my proposed modification is that it is not
clear what to do about RECORD-CONSTRUCTOR. If it were redefined as
(RECORD-CONSTRUCTOR rtd . field-names)
then
(record-constructor car)
would almost have to return a constructor for which no values are
going to be specified (for consistency sake). How then would we say
that all the fields are to be specified?
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂31-Aug-89 0231 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #192
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 31 Aug 89 02:30:53 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00581; Thu, 31 Aug 89 04:23:37 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25392;
31 Aug 89 1:12 EDT
Date: 31 AUG 89 00:04:41 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Subject: Scheme Digest #192
To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id: <8908310112.aa25392@mintaka.lcs.mit.edu>
Scheme Digest #192 31 AUG 89 00:04:41 EDT
Today's Topics:
MultiProcesing Scheme
umb scheme ??
Xscheme is a-commin'!
Xschsrc.arc (Part 1 of 3)
Xschsrc.arc (Part 3 of 3)
Xschsrc.arc (Part 2 of 3)
xscheme.arc (Part 1 of 3)
Xscheme.arc (Part 2 of 3)
Xscheme.arc (Part 3 of 3)
----------------------------------------------------------------------
Date: 29 Aug 89 15:03:24 GMT
From: Richard M Emberson <rme@WDL1.FAC.FORD.COM>
Subject: MultiProcesing Scheme
Message-Id: <3950001@wdl1.UUCP>
Do people really use engines to get a multiprocessing capability
in scheme? What are some alternate approaches?
rme@wdl1@fac.ford.com
------------------------------
Date: 30 Aug 89 03:35:37 GMT
From: Ozan Yigit <ukma!mailrus!jarvis.csri.toronto.edu!utgpu!utzoo!censor!geac!yunexus!oz@psuvax1.cs.psu.edu>
Subject: umb scheme ??
Message-Id: <3477@yunexus.UUCP>
Somebody from Univ. of Mass. had posted a message about the
availability of a portable/small scheme interpreter (umb scheme ??).
Whatever happened to it ?? I heard nothing from the author, and
lost the address after mailing to him.
oz
--
The king: If there's no meaning Usenet: oz@nexus.yorku.ca
in it, that saves a world of trouble ......!uunet!utai!yunexus!oz
you know, as we needn't try to find any. Bitnet: oz@[yulibra|yuyetti]
Lewis Carroll (Alice in Wonderland) Phonet: +1 416 736-5257x3976
------------------------------
Date: 30 Aug 89 02:56:44 GMT
From: jdm <usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!zardoz!dhw68k!hodge!jdm@bloom-beacon.mit.edu>
Subject: Xscheme is a-commin'!
Message-Id: <21721@hodge.UUCP>
I have had numerous requests for a copy of Xscheme 0.17. I am
therefore posting the entire thing (executable and source) on
this wall rather than comp.binaries.ibm.pc because 1) the majority
of people who want it read comp.lang.scheme, and 2) files
submitted to comp.binaries can take weeks to be posted.
I am not in contact with Dave Betz and I have no idea when the next
version of Xscheme will be out. I only started in scheme several
weeks ago, so contact him via BITNET if you need to.
The files xscheme.arc and xschsrc.arc are uuencoded and seperated
into three postings each.
Have fun and keep your nose clean,
--
"I'm an anthropologist, not a computer systems architect, damit!"
jdm@hodge.cts.com [uunet zardoz crash]!hodge!jdm
James D. Murray, Ethnounixologist TEL: (714) 998-7750 Ext. 129
Hodge Computer Research Corporation FAX: (714) 921-8038
1588 North Batavia Street
Orange, California 92667 USA
------------------------------
Date: 30 Aug 89 03:03:19 GMT
From: jdm <usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!zardoz!dhw68k!hodge!jdm@bloom-beacon.mit.edu>
Subject: Xschsrc.arc (Part 1 of 3)
Message-Id: <21725@hodge.UUCP>
begin 666 xschsrc.arc
M&@A-04M%1DE,10 1="P$ ",2<SRB+8T! ,3X0HB=$#SYPQ:,JT*>/B
MC1@U( R26=BFX<.(<\S0"2/&(D2#:=J$.</0X<<Y:=YXQ&AR)9<&"@S"D9/&
M#9V5!N64"4,&YYPY>2J:Q&BFCIL8/HNZD>%3)!TT+F&V↑4FGCADS'F'"#*A$
M1D&4;M+<'&IPS!NA%T':S*H YA C3((<F=*C11LV(%J8R?LD[Y&\=UK 21,&
M< LR9?:V"!RFSIR\2<;HX%)5CI@W8[C4',.F#F*M"ER,\:@#9@(Z8\;D54T"
MQ=NX<U. (,$#=-F$"UV4P5-&1X+67&/(!BY01@K3=-C47 ,"R&V%#-FX60.:
M↑, 4OI_G1@/3NO'L!W$S1(-1C%G$+K@KT :"$U34U151D8N0P !%UD$
M+Q'CE?6?Q2$ PO5(!H,V<.G3IFS+@8 Z+%P#DMR+R9 V(.G#)CTIA)PU#.
MFSITTK@I0U'%BP8*4(X0.89-'3)E0/"0.,<%&A\J6;J$"4($GCECT)1I4\:F
M")0J86X<"8*)D"E)M!0!(0,&#*0* H(H@X=.&3ENPK !82>,G#1AQ+ A"<(D
M2JY>P3:U$H1)Q2]UW(CYZ(8,"SIRZI39\;;K5S<@C"1A,E4%'3-P""N >QB$
M2#I;Y8!](QFE5C9OQH@E:Q:M6K9N%1@,$Y)A4+,@V(A!N,4I5*E=)*]N;=D-
M9C9P)M9↑&K5(;I2[.?;↑+1(F'MUT6"N_''L,7SK0I3.D#GQBFI!OW&3G#=K-
M&1!RYI0I0P9$#Q QF'3.*M"[F↑\->W]'RR:-GIBIV?<="F*$X<9(<J2 $@@@
MO"9'6P4>↑)5D>RP("0%PG.6;&2B(4,(<7+@A @L1(IB"9"!<V-T<↑X7G'@@P
MH*AB<UR]&*.%!+!A75Z8O7>C GU@I=5$2Z4Q!QKYM52&@2#4 0<(8I1AQAMR
MQ%3E06")=!X=;X! AU @O'&1'-*95U$>!@W5UDD*$"F2D6B@H* "%0(I9'WJ
M:49E?AE2Q↑17'CU(5$%AG $@FQ,!2B4*!)TQ)X,.MM4HA3CVN6&'BLJA P@?
MACABHR>B%&1*](4Y!YE]Y7=E'7*%@9Z!$K4!@AMUM!'E@U'2<<=ZB,$ JRS
MMA##FBA1-Q&J9*#@QJ/+S4JI BGF&-YY:\0P7[1:M1'&&C'-P6I,NX(@D1LG
M8&8H9@;5,<8:OV+VGT?$0GNA1B"@D-YZ[?7@(Q,IH*<>>R_&=↑V%6HEU!I7?
MH2%K=-PB9H9'LA(AAPL@$/&&&&)0I,1'8(G% @A.O&''4+?"EP,.-7P,1Z$Q
MY3!L:M%6↑↑*] +\ GPPW0#+ #/+A2"\*]OZ;+WPVX ###78)%#2↑↑<DL4 PX
MZ\QSOPXY314.,]C KTPP\HM2 C2WM\)[,L1 PPTT8&W#V3V3BJU J[;Z:E]O
MR$JKK5]!68:NO,+X:ZIN"!MOM'$C!O1E*2P-< GUEN?HLJ':2>J0<X0A9AF(
M.70Y8DR& 50::8"PT5KQ*L986Q-9?I$;RH9!% MMO $3LY&J$-;K*L0.T[.$
M[\VJX5.NWOKKNI>10N2C>H;G7JOGM_FO4(ID5AZBIT%Z:J8W-A'SF ]?!NRR
M&[]@@VC 9KOKW↑<>/N\71BI&\5O$ ,-Q\A)@D!QCP)$'@<6#/_L.%0&,:.C
MO_"Q0 1B$$'D>H<EX&W.>R0JWO$DD[Q23:0EB4H2:-0#O=$=JEB↑,14&U8,"
MR# K>VV!#/L(4+AZF6&$92@A'"8HJCN9RBML&(M#SN4E,(V!554*H0=!$!P6
M@0<QJ7'<#<N00QF><#&-42%*ZL3 W[D0AVQP(O)L.)%_L<LAZL',EV+R0\U@
M#C-#+&*+D,@F8Q5D/6N0(0O>D) PLN .0G'#&,0'K<1 ,861B<VTPE3'O0&0
M.GC$W!Y7V,(2>E&.=#2#'1.I1↑-M<7)X8AD=&++#O4'/06$80UQ$![&__>IS
MH1MB:MRHR3$X<7PH5($4Z82C1I[+E2:\I/),%08X@(231 3))\M')E'FC4NF
M]%Q&4FF]#RJ E;[<) J"P@(3CH\Z00%@+&=)Q0LU,IJNI&8N*<C%.8CAEOGA
MH:M :<P'/:QNT!.#].1 /56V,83;N↑4K↑[C-R$RQEKZ3"PKT.<X:8M)48@ G
MGX2Y3F*&<I3(=)4\PT+/ZEWOGIC9'CBGB89JSO":(<RF'T\G2W_2LG[?_"5'
M/4I#R>UR(G1 9R<QTU"S/#1O[UP8F.+2!NF-997X-(@↑Y]1- F 3#0,C@%:"
M@A%V3>E!$D6(&;X",':.$F;S,D/C=N2;%K1@3F +J.%D0YO↑](4K*UA!%R*'
M(ZVH$S$BB69L1.+,:#UUJ]>Q$0 !"-8YW.$[0:E78-↑#AZ'VJTX)$ T'3\ %
M.9Q !U]+ %G-L 4=72>M77@18\DEF00D \;9:QC3P0"T*ITLR<@[8K6J-?(
M_NPQ'U6 9↑VZ)Q28U3EZG>M9\< UR_((@&F]+5? JK/4;72RE:41'KKP%Q-V
M5K+*S:UON]J"YS82N<+% V8CEUC/Q82Q,)#?8[↑FV.]R(08WN,%X99N GTV7
M#H>-;+3>Z]7G1@N/S6R<&H\( A_$IHB5Y2H=U@H"Q.K,M-($KWA)BV!7G@ $
MJ05@@U&@8!A$↑&LZ6↑T1ZRO?"XW*LQ].@!BJM*W.EA?"7(#!#&2P7L_BP0PN
M.9*<K"O6>A7A"4;@KE+"4 <VT &R[/W98-_#6#H\F ]\$"R2?. C/%0%!"8P
M ?FX!@,\W"#'\67O?&=#V?=F]CW9['". .SE%VDX#>&Q;U:5[!XB<\'(Q!V
M1 J,X0%$:\(/OK!L==8'$."7="@([G[1C!@IWX"["8@6$SEHX %,."BJ'71X
MTJIF H1XO@*F=&1#O.B8(#;1%WIQC..$Z&CY%;!(XFB69]L↑[Z+8*C-X[&=]
M+*:UC"R+)TK 4L,#F#>PH04,20VK"7!B\!Y-UGC0T5H,Y*09ZUH@UO&-1WY]
M'F&#FMBN!F]5D&U9WXA$,,[>M;1]W8(G63M:Q4[QBF7=R!OG> ?/;A"OI]T"
M/<1KV#ON\8\]VTA(5SK$'QY5!2E'!X4Z1*XU+29$NS1&+WVEIV'Y*:(,LE%(
M@Q0S83[IV\C75-'M*=J]'HM5OU(2-D7K@D)9UXRQLO&/%%R8#1_Y@[!J5*UR
MM,TH)M>J\=S8")<VM"'2LV0EC1@?R<C2..HTG67[:#1P]\R37H&,!E#!% U@
M2""1:\P=VDXO,7RGJ +*6>" QOQB=0"OM:9LC:M2:L)6EQ:< XSK<*3\S+WN
M#>>I3WLC5RY/=>83OSNI_UF_[)I9P&8F>FM=&G>FKBM)*7?JQ↑?M:_+9M)T4
M(0.KM+05/& $)(2.%\J;*B?"1↑NH1Q<RD@CK↑#@>[VNGWF2J(;WT[BXVQ3!@
ML0[B#7)ZB↑'>=Q;\RF5[9]F0.(XB$((4BA"$)8QH#GC1"U_(P-UHC7A):S!Q
MMG$?Z]V+.↑3 !GZHA5_]4-,:#K9FXO"O??T2DW?[N:>!K+]/;\P(↑\XBF=+Z
MK7]\[=\↑]]W'>Y3W:R7W-?>%!OF% GC0>G(" B'@9KD7 ZD569W%?]C760)G
M0WB0?UT"1FCP!G?0&T↑E+?SE(KU';O;')LG!$!OH!OI'5,J3=(8A%]3A@E7R
M/6<P!J*10W-P=)0A%TK$)='!!D?G/K1A-/1C:I;R& 2"$ <4(EN0&#>X*27@
M%R!P!$/0(&+!!G- A59(!6\PA%3(!NW1!2-B@!=B@↑O! CFX@USX%V$H%@MT
M(8 23??3A&80.:DQ< (A:G2') XA>#T4$W$E3&85$WZ7-\"R&G) 4[-2!B%X
MB/&R@J5%?J9W(40R:L-W<A1W6D$'=UI16'L#3.ID>0J'4Z64=P↑W=W_U)2ZW
M%4'1):E!B=0ABM($@RA58P1"$RAP RP [_8+U)694;P;@:U2PVV4(XH<UXW
MB XG!Q W&K,8';S1=,R">I=( &+ BS; M0$ Z#8AZT'>1UW5PEW4X"''-0X
M'2&T@)%7>AKG3;JXC1.! MU(C$80C% &(WA0C.%86B(A!GG@%:JR).TA40,9
M$SEE2H6(&<'1B/'"!'1A%RTHD%X!CT5%'0])!V[ &3@BD75!&D2((V4Q%H3%
M!F<0!AN!!W<S8T1$)1S9)>↑! HAS+BO9DB4YAP20;&S@.=$A!V>PB?+80()E
M!S=9*T"C&%A !5D !460 G&% AO9D2F@,↑1T4'C@<A89$PYQ!V=!D A)D!&%
M&"XG5QL9D1-96EJ9D!CI,R$TE6] (@EY="!I%R5Y="7Y(LF6DD?9!BX)ER]"
MD[Z1 C:9!BR)E#F)EZ-QDGQIF"U)6EL9F#6Y-WV) HF)(SSIDV81E#I9EE()
MDQTIEUZADXWD!(OQCRU(!SA@ _DA$G;P!MP"/7. )EXA*Y<!*$Z2@BA1EP#I
M&ZO9EO63%Z&W?$<P!;U1)6<P!W,$$LC9@SAR/↑J"&5- G,9Y*F60G'29EJZY
MG'1@!RQPEVZ)&9?1D4GE5I[4<+>I&;DY*[52,L#2</UA$(2$'M=I)*-4DH)1
M@/63EXRIDHZ)E*0UGC)9+Y/Y&/_IEY=9/ZZIER@9!B,C2HO2F2!A!PR:D@_*
M)7(@E#N90YH)E,/75M 6><YXH7NR%N;Q)?IY>C9W+BSR'X)I!_WR@""0 X\"
M"0B0;)G2(2Q!)54B2F2!$1@:&YAS!E\R(JZIDS_#HOX10RX'HP[X'C3Z-3BJ
M)QDJ CMJ1CY*H@]BHD2*!B/2I&Q5/Y_Q!F'0'DL26,AIGZ@(3↑CI!G*EI8-S
M(?P) N?"1$-Q1B\:C*GG!LWI GC@ F' 6S.YDG!@F7(( C] H(-9F(>)H(>Z
M*>"HF"9)IWMCIT3A&WD: TC*I]=9$W\J!H+J0H99J#F)J(H*7XR*DX\*(SHY
MIW6Z%I=*0-LI YO:IW\Z!J%:0J-JJ&S0+XDJF*A*F0?*J_T"J:VZF)2*0W>*
MJ=LY [7:J7[J F20JX1*K*8*K(0IK(UJK<8JJ2_RJLLJJV[@G33PK,D9K2P2
MF-5:JK]:H)59JMU*DL@*KK&:IS5@KIXJK:$SJ+O*KJ>:K0:ZK?#*JM[Z'O2*
MI]MI SIIG>?*%OP*6M;:KHNJK:K:JR 0K_LYKY4*JP@[KBQP:$?'L#5!!A3Q
ML*1ZJ!(;K %;L<5*L/(ZJ0?+K!Z+ _@:K6, 8X6BKOV*LO↑:JHBYJI'*<@0C
M$'/6<+.9)K;I&[A)=G%J5+YI W@ K*%I B+1G"Q@ BYGM28@LF&Z<09!)3'1
M<%7B+3Y&$2+AC&4I3'!*<V%DJ7C:I+_HC48YK"B@E$SIE"F0M=#ZIX':4J:V
ML>&* G ; W);F76;!$O9E$↑IM↑?ZJ7C@MQ?2MAR+J7 K X5+MW:KN'G+G'N[
M$(↑[L(!;KW [ Y>[K8>;N'C+N/DZK9!K/Z'[MA/* C10NBUYNG>[N)S;N"[
M(JTKN8$+MRDS!G-KNIF;NKF[NFG0NZ]+N;';C<)KN,7[E"+K B2AO,HJNK'K
MB\↑+N8A[NRDPO21KO6[+O-W) CA NTAINYJKNC:+LXZBDR!*GT0IMB2A;W,E
MGS372&!ZE;MT+B/1%>ETGF#ROV77J*0$3ZX2G[JI&NNX'2'DOW AE0K,++RI
M NAGGRO$F↑"IH#87;1:! A8\P5F6(@@PIZ*1H2%LG]R5PO()9F2 PA=L$-SU
M,R&PKG((5L67HR+ %1<A2IS')+=I*'(P(@E*PHV$K3[KJ+VJDZ-210(5M(P7
MBD=;F_G!%9\'EF>"M/+6!MJ2*JG!FS]!FT,!G.A&3&TQ!FU !CT@ D/P!$W0
M!$'@!$0@ JEG<[%#8D Y!W("5F@\-!QE/@![/UJB@ TJR.:QQT>7F8S(F4?7
M2%,\QGW<+_KB-XD*&()QL0TRO+4;O2D *%2)FN?"+=0S4] CR@>L4S$ARGMA
M%NWQQ6EIBZ),QN;7DXNLH?VFR>G+R;;H2E4Y /P;=[-I*[Y&$0YQ1GDS$171
MPQJA',&\%UPH>@61!\+,A< Y*AH &@A53DE84U151BY# 1=6 < # 24*S8
M#@ . ,+U2 J.,F#9XY=.J8,>-B#(@6 POB 3$'3IDQ:<RD<2CG31TZ:=R4
MF0-"Q8L&"E"."#F&31TR94"(.#@&39DV95R@$8%2)4R-(D$P$3(EB98B(&3
M@-%304 09?#0*2/'31@V(.R$D9,FC!@V(TN>5!!U:E6A5H(PH?B%H!B/;LBP
MH".G3ID=*,M2=0/"2!(F2%70,0,'+UFI>T&$I -53M4WAE$↑9?-FS-6L6[M↑
M#6L2)<(P(!W6W J"C1B%6X86/=K%\.?0BMTP9@/GS9S41(T6:>V9#NB-L6>'
MA(G'M6_8BTN/@4O'↑&↑'E-V< 2%G3IDR9$#T !ĆG FV'3,,8XGB05]/H
MB=E9@?B"=%"(">-&I)P4*$& &"VGY/SZ5!FV1WZ0$ '5[*9@8(()<S!A1LB
ML/"??2D8!D*!; P7E78@P& AALL1Q-AV'J+41U-/V094&G.@\=!↑8-$W$!P@
MB%&&&6_($9.."545TG1TO $"'3:!\(9%<OPF'45Y('236"BI.%Z+*."GP( *
MG)@2>$9:YUB.+QZ8G(Q4==0?3G/,$<89[(UE6YDYHM#&'&=8J1]_)<UYAH $
M&HC@8 O"*8<.(#3X8(1Z5F@BBN'-D61<+_)8QUEA4$<?&6↑T 8(;=;1A8W\V
MTG''=7S! ,*EF[80 Y0*)&?;HV2@X(:=P6W*IP(7$A#==&O$\%VN3[41QAHQ
MS3%I3*."@*D;)S#&)F,(U3'&&J<RMEY'K.::$0@H5'===CV0R$0*U%F''8?=
M_5K@4U>=D2-Y:&CJ&[%\F=&1ID3(X0((1+PAAA@D*>%155>Q ((3;]AQTZ?<
MY8!##0;#L69,.:S:7JZ]<NCMN2]P)\,-D PP@W=];HM"M↑:"RYT-.,!PPUH"
MH?SMBQD+%,/'(8],+D0U)X7###:,"P(/'8Z+4@(;9[?"=C+$0,,--/QLP],D
M;PFL0))2:FE<F6[:*<.ACEI&J:="ZH:JV1:8-5\G+Y:"S.>6P.VN*<RJ:):,
M=AG&D6._R#=?,H8Q!T9I@* 16*SZ!5A)MNUMD1NRAH$3"VV\ 1.M>*I@U>0J
M5 [3K;FNS2V.CT<↑N>=EI'"WEI(U↑M;C?L->J1@A;96'X6D@WI[B@=GV↑MBF
MET&YY:GGMQ\:I&DNN?"=$P↑ZVF7TR#;IP&\N/.JJ&\8ZE[:U].:+WEMW*NZZ
MC↑7JX)19AP)AM/)>$F'/$R#Z↑N&7L3X<V2↑Z98I.LH$51,\:4I'&,"D=R89\
M,:G-',B3AC?PI3V[ZM)4_'>_]OTE,/!#"99"%[U)36↑";*C@ZO)F&W-1"R+6
M80R18D) QXR-,8=+H'A XD!6G<↑$]V/!&Q:20A;<P29N&$/Q<-67"[ZO,*5Q
MX'1V:(84[J!6/QR;$.,WOR9>9PTY9&(/HQC$U(UP?XV:&!T< L#HC8\_81B#
M60QWK[*=:G!I*%P,;7C QCUK#!4TGOM4D,$K]6E↑=Q2A]DBH)CA\A(P@,"1C
M*H5&-5)E2$(*'!SEF+LVH>1\85 D'FO" O89+SDU>>(>↑[A!Z$F/6YI$ 2?9
M]\76=4D,=WQ1 !F)O"0YLC_VZMKL:B>'V\VQ/>>#9?3PZ$DBCK(P&OQC!\↑"
M@D"R<I!@?*4FP_21,]8RC6L,TOAH9Y5>(I".C/%=*E>)OT\>,)1%7!P?D>E'
M7)G2@Z@\I"K1T$G\M9)["(EE&1=YO*U@\Y&YE%>1S-*&VF$%F'7,YS"KE$QW
M$@"4:% 7 9Y2DXM0"T?]F9U"S$"5<S5RC1<KD,G8$"+9M* %5D+:,MEF&M1D
M*"Y16<$*NG"W/CUEEGP)B2)+$Q)+.A13(,!2 LSPK#F@H*5F8(%J=,,"A) A
M)'?+51] \,-*<NNH)1T11>@"%L@A577:(5%-'?J4.W!E*HI1H9!6.*1'#8XK
M<("A54/Z4#-P:S#E5,!0P714#4V$1$]\*7&&IASF/%&F@HU*2G/5N%0B=0N)
MQ4,7YL*↑#↑G*KQSR4&%%=%*)/D5T;-5(=1CST4?2=7Z/C:Q,:0I-5]J&#M.$
MR$YIZ<];0E* ,2&H05GUVG&B@580C1]%;3(MPX%I.;+I"%9*6YVT$:![Q,7B
M6*]FI(_LE*W,=:XF:SG/Z:XK/-:M)G:O:5MMLI4N]'EK&N+Z3;J:#*\I;:P\
M.0G?UN+3#"YIT8OP6P?]GI<J!;4*5G1:S=,LQ+1NF@-_J62E4EX6IG_=[ $!
MJS_7#BZZX,,P1O?C0+J\8;GD-0M)R#"I'T$%#Q?Y2 ,?F."*3HNA[=S>4P[2
MI*EH"B)123%:*S6'&C]I.6T0%J3:PX2TK(7&3FH#C!V<N3&T@0P]$$&+1&!9
MDU5.1ULY@U%5=S0GJVR>R4M!4>GR(Q3@@0UG$!R9I5.EJ!;HS&Q0<Y:K9-GY
M]3C)JGPRN<+5(1#\H*UV 0&AQF 'C>"!4TI&@5↑P0(4L0*$(*2B3&]Z0/[Q%
MLX1Y\-2'28)CV3S2-A2Q"$8TXI >:YH-)&D/ID↑]Y89J20, @(04 !H(6%-"
M0T]$12Y( $79($ !T$=.F*7=W" #"]4@, S1\R8-V3*N$ #HL7 .6/0
ME&E3!L3!-G#2L"DC!X28/'0J'DP((J&9-&[2T$GSQLT<$"I>-% 0,,&0-W#R
MR$ES!@T=$"C&I 1(P<.'"P\Y@%!)(R=-&1 -$D3,4P9-B"$E*&C9V:"(&RP
M2N'I\Z64,G,XVBE#QBL4CFW2S)G#T@T(N2#.R GC)F14,V\ZUG$C!RV=G6/\
M@G#3LL5%BG+&I F#M4[:!#%GSAQA$F7%)U"↑")%")4$"&'A@Q$@0T.->-Q%!
MM 1QN$[%S HXESGIYG/HT49,HX8A@[5 ,:]CSS9#.2U,F;D[]P8!6K04X:EG
M&'?--_;@@V[(J*Q+F<U2W+IY↑_[")$GITZEI;&?S)DQ4-BHY4GZ↑6?KZ(U(4
M$1Q\,-2PW1GTB;'?''FT(<8;6-E!F6W\1;>;9]2%=L041;PWG W;I?43@F\H
MB!6##D((@H1L4(B>?QE↑442 PZ7PW9EN/&4'"U1U->*8>P4AA@; =GB;="E
MAV%U17#H86I!A+@5"#GNV&../TDH))$5L>ABDC!6-T405A2!'0Q"A.A416%8
MU-)*;M01QDJSO7CA=-4-$0033)PYQ'9CE ="FV9\1Z===JH78X!45"&%$P02
ML5UA=-0AAUUF\-C&H" 4"MNA%2J)9VA/PF!F:_39!\()+)X PATJ,?13HDN&
MYD02?1(8'*KU1<4J9:["2@=#*6%%ZZA?0%'%%$A@%P,,V\%AF:P2K=HJ"(6=
M(5=('1V[WA!,/,$A?#&LUMH8A<W)ID7TS6$IDII9J&AU1D@11!-FHA9#<>>F
M&Q*GO=U!I8YI:(IEIWM1%&J8H35A11!2'$&N=JVU\<9:V)811QT%LS6H'&?4
MX>-/=+R!<!@*ST'?K&#>N9[#3T LL;[R57QQ13@=NE↑0(8],F\F9HER1RF↑P
MW)_+,3IL;\3D&MB:&!RS$55A<_S$L\@'\Q65Q1B7?'+**R↑,='5!$"$%:.3>
MV!H9/,)!6[54__2&&6↑S"3+6?;WD;8Q[!C%%:?I&67$8:PS];MV%?5P18R!8
MG/C5(↑O=\KRA$5$$$T%D06Z:_9:A+J=P:"H7O H<3?D7$ OH[)↑MA3'&&&B]
MU*:6DW%YEUU\#6RE&S[O3;:3SDK:FHB<TCYDD2@-:E>5!5_Y(VZFUXHZ%4\T
MX>RI LWYQJ:ALT75Y[Z'5D04SNXJD,8_@-"]>('↑&_X73E3!)W8R0-M:G&&E
MCT)@BQ4]U/K?<]_DI#>$)SAA"O0SET# ([GH(4M/UX&/#/BUP"")[71#,!O]
M*+9 MEU0>DZ"H 1K)A 1.29((?@@LD*H0=3(P&DEW(ICV)9"Z,E+>F63%'QH
M8+_LD2$J=+B#R>($&:I0"0_=FTM=&GC#%58A33M4( C<)8;#N(YD0EP,UA!S
MQ"32I25,%-7+Y(<=&E"P<75@PTK@8![:9)&('#%B&9!(M2↑Z1(7KB4(5GE!&
M#I8D#4\A21!-AI*0G($C7:SC$O$8(R9, 8$[)"$(-C*7M↑7N?>/+%6IH $,J
M;6P_7GO?$:@0P4V"J#5Z\1RW+(DHZ&@ &@A84T-(14U%+D, 1=,0< $42
MYI['T_@, ,+U2 P#-G#)HR;<JX& .BQ<""!Q.":!,FC1L0<M[4H6.Q# @5
M+QHH")A@R!LX>>2D.8.&#@@48U* B)$#!PX6(,3D 4$DC)TT9$ T26,P3!DV
M((24H:-'9((@;)!*6=ER#@@I9>:4D6.G#!FG4+:V23-G3IHW%\F".",GC!LZ
M7D&8>2,'1!TW<K+243D&;E W:%N,>=,FH9PQ:<(@K:,U 4B1(D=8',.F#AF/
M(@@:1*@0C0C((P72.0@"3D:V8=KD=.MFZ\>0"D9<-M,Q:1 G3HI(22 "RY3-
M$AU:V6H6+0@8+F+<↑*Q 9,"U;-Z(40S"3AB58<2PR?I:I)HV<+Z(J6,&!)V3
M7[9W9;,#]/.]8<9XI+V]]!N+<.L↑5F D"9,B']%A!AP].%$%$TRTUUQH()2!
M1WYN4&<==MIQMY↑#$(+ A!5!,#$0&V;<Q0(>V[EAQXAL6,>>2!AN==&&'8(P
MQQ=ST$&&12S,6",9&M&1(XTV;B7'CW>)H9$;9"CHG$ MRA$A4AEMU)%5%S[H
M(@C]_??1&V;15P8**2C)($46-60>:61>%"5'K76G0)I@BK2'2"! 0@",'@YV
MF8)U$D"GG<]9E 9'BJ6AAT?[]<FEH'2@(,1MN4D1YI]↑*M#G<WG52)='HWDT
M6QAUL.'2'72M,0<<\96!TQN=RG$'61Z-D5<8<($0!@BMW0$"6HC"UF<:Y:$0
M HEI9'I>7BAD!A%G+MQAJ@@II. 4L6X,>L<<*-0 R0#3+K@I0+Q>*9'C";&
MAJ&TGG61GO,56Z.;?;(+0@\?EO'65LFJD(0325"11(=):%&$"M#R::>\]*)@
MY%UDP '3&Y?)],-:2ZE8QY?LRJ0#"/PRX2VE[[4%1X-R9"0'E;[:">Q+6M'Q
MG</GA:?>4=&",*<""2!<[[URY$O%$U#\9T413!#L;<X0>Y3PPD@ZG#$($Y]1
ML6(7/QPQ"!MW?#2)(5Y$+XGVVC'OARJ.W;&""9!XZMAJT[%&S 83T =HX#:(
M1QEC;,0IFA5=%-U)\*H<K+PAT*OUM-O=G3=<5I?A;9]WB%R'P][.O2")T85!
M!I@V6T[B8&]95+5,>WC.AABSKL'Y'A_&/#,;8.X @NF4E>'6Y*M;OF3K)[UN
M9EYTU.&D>6↑,2_S(ON]'HNMEK!>G C?WN2,<&]78LPA;K#;&&L0?#X+O77#A
M1L&41N?&&2↑C$'-ZS1_%0@R5NR<0UQ4AY5!><-#EDELDF↑PF_6F 71OF< 9I
M60H$1='/ ,↑@H.C9"6PEHPL*%D@D-S"-#/%;T',@Z+_[E2%_<MC?181$E_]M
M)X(]H↑!U"D@G!*+A.A]9H.SP9"LY,%!.( L76># AC#LI%/]*V%"RA(&J06.
M $*B'AVLEZPBH'!CY+.4G9)8O;U,D("/FV+)E,A$$8@OBGW*86E4\A;CK; .
M"2FC<6ZE%52UI5;G:E.B!/>2%8*@<#+Z0I&.A$&;.86*2[2B"$ @B@F((ED
M;-0*LR@W2HG1-/@Q7M?ZHBX0W.$@>3$>">ORAC'DK61QF2,2MUC%Z[T0#G"P
M5UPL D5&(A(_*.#:73XF10(\9PR*00H07XBD$QX1EU'9)"_)<,+8B41W# +F
M"4TV3%\Z1)F:1"$(FNF:_2A3F&XA)KX,Z$ D6FEX+Q,/>7(RAB_<Z%2T,DC<
MQ&@1.[QA#7OSR":GF4U?BG)EL4P1=>@E-3I8[$M@XUF↑=".%)TBA!4BX#1'↑
M(P6C<<N/../29K87NP0\AW\G 6'PJD6''Q8/=;;C7H]V59Y;32<HU-0/;')V
M$(K*X&C4FP,:\ADVF#)FIK)TP]9Z:$.&T$L&:"-1&%#)ACP8$V?F0Q]X%%;.
M<Z**#@9Y'R.163? T+.76\&)&ACCDDPM17O<.X_Q8O:]]B%%E$E-W_I>)U4%
M(7.#/312",T$R3+R;YY#G$,1/9)-6\G5)<J+J_ZNR,(#)C"&!&R@&)W:PQ↑2
M!J]9T:L110G(+@;AKZV,6V6MN$!7DC*0U_LB(Q↑92$G>A9+&N>16XAE$3GI2
M>'D)"F4_V\53IK(U06%E(3TKA[HV*J>TK)M773*=[74/B&1-7LH((-&6JBY,
M%A4(1E&IO[L,RJ,Y2=VN-G+$M"YUK69MZS'E]R$ST(HZ#O&MK>1R7J1 EHA&
M[*N#!F5"\])!,80U("$/JP(9XK"67-ID?C6+AT&A 'YN):]%YF(FQOH0!)<9
MSQG.8)$S@&#!=*$(1XRS'PRCP QM\%$88L"",,B@Q#,H,0WTZT(8J@#$=%!L
M+0\['C-L(08P@$$76* ".,3M5(DT@\+(PP(8EYC$)D:QBADYE[J@8&3TJK'L
M>GQ'>IV "S X@>P,F NT4&)8T!!CU>P@@SN+G)#G9R9:L<_-<NWP"X1*Q!/
MLI5TG4]&>:@10MR$9NI1[K↑_"I: X,!EB49'*↑H;$".Y1)MJR?2H?9IOHV!@
M9@5H !H(6%-#2$5-12Y( $7;L6 !.$G*DJ),;- #"]4@, S9PR:,FW*
MN$ #HL7 @@<3@B!3QDP:-VGHI'GC9@X(%2\:* B88,@;.'GDI#F#A@X(%&-2
M@(B1 P<.%B#$Y %!)(R=-&1 -$EC,$P9-B"$E*&C1V2"(&R02EG9TJ.4,G/*
MR+%3AHQ3*%K;I)DS9Z,;$&-!G)$3Q@V=KB#,O)$#HHX;.5CIJ!SS-J@;CBW&
MO&F34,Z8-&&0ULF: *1(D0%!S,DSYVT;R7#*'+8X9F+%BQG->G2L8 1%BV[*
M@/A"I8H4(4↑&?'E<↑N(8-G4H@N!1F<S&A3Y$CK"-6S</OGDR Q=./+=JWDO5
MM(&S7 %D@4:>2+D21 J1!'22JWYC!D28N'/OA)$3E.+M]6$T<GPIDW1D)K&#
M, $O'@1Y\R"P\<88B<5E%U]FO519?$35%])( @5A1!-4)) '"JY59Y<<K01
M'WITA4$&&7B1A=5+(I2 AP@.7@?"$T8804464!21@!MUM"&&5B#0<9!D:>@Q
M7GEMF3=BB1ZA<!$=+4((@A%)8#%CC0F0$=]YX64&8EQIX $7'&\L"0*..FJ5
MI(!NG-%D9$E,::-%7@8%II@7P5&'2X*YP94<9<TGQQMW7J1:EJJA@.89YM'Q
M!ALHI+"F0$D,X805%L+Y99ANH>6&G7ARM&>?9_T9:&HOQ;?HHR D,6&%%V9(
MQX9S>>@2AUS&"<*<F9*Y(Y\HEL &&2Q↑]&!D1N#G9I57]M@?K68(R&":MV+J
MDJYFOM3L&_&A&B.%%F*X)*P=?LBLLQI!B↑NT.>Z:9 DNQ%"#FL+2%AFM/JK&
M!%5TS)$97$. (-AT:;#!HT--A'&86V_,P1!IPYEQ&@A,3#&$<*<)"H*$W":0
M(ALK4OP9J3#*2*.-"1SJ,6JJ.9'$?@F@8$>80:F0 @PG6]Q$$$,DX0053TR!
MA'!EN.&;&?(*1.↑/5:B,!0A34&89"%: T.↑_< 3,(\-I.%P1"$E'";3061>]
M9;T7Z_%69U,/5K7 =#D4A%AGG(>UUN4%H0451<@61!-)'!%$S:1BS.K&'9=6
M,<@Q'ELR1V=\/;381ZM6L!QK@'!%P&P@UH9':0/,=D,7T[%>&DQ3$6]M= MU
MQ<2&?ZR:X!82+@+@JH6LN,FE!?VX=4Y&+A11?\Y!GDO]UN "#/ZJ;35=<S_<
MA,2T7[QJ[+X6;IKK+R8↑LH6X7X]RJDY,4<01312Q,PINL#!'"BU#,H#M(Z>
MODP↑↑#"3#3+UT,-+*,!?H_SK T'][N<H%WG/9E,@0L\:0C")@<!XR#O<B7R4
MEC#<:3 ,(E!4=L(PW86-=_.:2X]↑1(4ZR$$,;Y!:\CQWM0<U[&&L<0UL9!,]
MV&FL>K-KW??\1[+N21!\XB.?↑:B /O6Q#P7NXZ'\W$ _↑\4 ?R#0'_↑4B((
M#O")!=0A A4X!<=]T$5E$9)_RE,&@S&$4&,$04+:,)>=9.4,"<G4W(2VM?!-
M(0E:*$+T[(A'&]$ !NY+0&2H19?__(4B'LD,70ZIFC?&T24=!!O14$?'\EAA
M"G?,8_0NF4D;Q0"0!!"D0 B91B9803\G2"2/N,(7$3HR:)!TH0<GZ:+36) -
M+DG#=.8BNDP=+C0<&8T+LU;))VF'.]Z)7G:VTQTB>'&2#2LF?H:@G↑A-4S\6
M6I!&QO!,YIBAF(*KX?1N:+U9>K.8/(P>#RVTI&Y2\F%0DM+(E!FEVS'.G=%\
M6)OFJ452[9-*BX.6J1B5 GP24Y↑2LD+T(C6I↑5EHH/,SZ#?UN:J%CG-CP))H
M,8OU!#<ITUC;JQ*@Q" PC<*SHOU4S;8&QRYWG2&'(S#G.[<VA7CRS0G1JVF4
M;FJA%GR2!CBHP0ULD%.;!@$+%OII4&]0 Y-N;0A6@ (5I! ]J$I5"BC PQ&U
MZM3RZ"R(Y=O90L,WOK 2,7WK:]G\!+@_$U0Q!2WP04>↑8"71;0$&70 !%T0"
M DA8P 0F> D3=P,"$+AU?7&=:UW#<->\KD!!<)7K'+X0QC(4-'>2%-MB*E('
MI/Q2/ATYW0%)-=4J>%*9↑A%? F@VT_*HC E[7%G+3*F?F;G311AZPUK"<)G,
MB25?HOWA%*9Z,Z0FX),PL%!D/(0'7>8H0$$[@X_2>)[*9 A1>5J0'%WX0R1T
M,JDYR(%R!3(9'2T*!&@(@\)Z% :2-C)(JF&8</<&!2:0#+GC39Y;_H24HK"%
M+SR: V_A(# 0L.4MIP.CZ,90.0]AQ$YL8-!\/#2&X 47>P;1S!H<N@>TE">K
M;- 7Z-;*@X&$F YK$(-Z+6OBRJSA#7MJU Y T(?HC<%."G,9↑SJ<M9?@(<1P
M$&"+4:SBK,@$QVC0\8R/DI4AOSC&*9AQC5-ZJ\4DV0[L:YD*6M""'XMX?SJ↑
M[&A5 R8X-,I"*%"!E↑&P@A6(↑8>*,G.6T[SF-V,O*W2(LXZUO.8HO@3+=OX>
MB4[BT);U>05@9N)E7;2>,↑0(E@$:BTO@L)ZR0(O"%I8O]GY\AJ4T↑LPH>,N"
MY' &])4!#Z(C=:/<%[T?1WC4I=YQCT'<Z,Z$8'\PD,F/%85!-↑1!QE,>LXG+
M7"(ZG'D/A][?CVN]@V##.2↑?MFS+V(B71L↑A42#XP4M8K ,3\]H,9;A#HP)M
M,4)]F@YP."*ZZ0QDF6@[-:C↑M$RZ_6,5DX%0[-97%H4-[U3'NF5<7C:IQX 3
M-0.YS>0F%;7+2.IK;S7" Q=RKL6&Z83U*(6==DFC'↑T6C_SG/)26PS8[NQYE
M:4G3W↑.TP8():E'[.]3B↑71VT\UJ*JL\<Y5I.;15;6Y5XQS=*:BYL%5>7A02
MM&4N/W?,55WT1=%\ *UF0]RL>Y%_AWKGI>YYJ:F>IJ='/6YO$(,:-&-L=6,=
MYIGY=-C'SA>OVUSJ88 3F70.:[0SO-1P<OO0X4Y(NK]<Z↑A+EU;T_D.5↑]?O
M2D↑[JOU+↑$W#G96*D@/B>;[T4D-↑+HU/.=S!)/+)9[WR*. \T(5>>+BG0?2>
MM_NG3\_+S%M,Y2?A9>H!'WN1NYY4AA?0'$Q8AMF#_C8)X_WM5:/RH-G!]XHO
MM?'=[B)&FOQ$*+>8$:10!)*Q5MA#>$+XDIK3+#0!-BR3 3VQX(0J-,%",_BH
M]LUO(1KD=*HZ.X*%FDKE)PA!"7EC%5&I# 7ML.H&FY1_VF$A.%!5↑#$%KD$R
M.1 ]Y4,%2/ $WW%<U_=#V4<$]Q4#.54%0B %225↑5(8%"+B!295↑5#8$(<B!
MQ↑5↑):A]5* S51 $+:A]QT5_V(<$W9%4↑R=L4" %3\ WJG5< $AEYD,IQU6
M(#1*;Z ;S1(&9R!,#-@=2\!]5&9?,F(A'HA;O!07$=:$%_8]4& $7Z S4% %
M%8*!_ >&3T"&8U@A'JB#8"@$.M,=69 *MA\X38F2:@:!C,&6.$1%>>$5.86
MXI%51]0_VO,_A&A8,Y%M3Q(EY=<$(-!MA)A87T HB↑8D%7=QGO$6'6(Q/78>
M?↑$&+8 12&$'B5$'JE%!T;(D+10]8W$N6D&([?,↑AU@$\J-5BA@#↑8-KEQ@9
M:(0A74$4\0%]+Y [M-7!Q ]IM(&LJA6N"A%KP4"?, '8X)ON'AK4J-]4Y!P
MJH$C4=&,*)"(T+@RW!AIE6%F6N6,NP@"T3B-U3B(S[@_V1<↑Y4A(Z%B(N A8
M[Y@9XK@_\?2(TDB-@LB/\?@D↑/&(Y8A"=D$&]]@R&6>*N-%[U[@_DV47"BDT
MY<AZMB>+H==ZB:B/*)!Q<+"$3?B1(/"%8>@$:R@3V#AQ5%9[ZY:.';F1↑1A8
M(;D4([F%UY:/)XF&:DB&+,F+8E-D1/%\MX(7OD$@HB8LQC@ R&ACP=20X5B3
M↑RB1ZSB/VQ@]7'<&4OF1@3605AE%↑S-<4A!_Y=AT;-"55 F6_<@TW@=↑Y2AZ
M:BD3↑LB6!=E_4D %Y;AV9#>7AO65UKB.]H=_0Z"7T9-WX.B55=F6_VA↑Y7@M
M\>&7=1F88FF0Z]<$Y7AY<B"9@ F/ZV@% B@%Y0A\NX<7G+F8!3D$!YB HYF'
MIVF75PF!MA@]">$C2?B:E"E%#?B 1'"6=2 &F\F1B@F;E7F"Y4@0OQF<,CF<
MN;D_(*B!HFECZ:6<↑$B7G4F05VF#T4EEN24668&;GEF9.]B#22 ↑Y;A\B;F6
MS0D"0YB0;[ H9;0IPEF0[2B0ZPD;3V!?0> $O2@0V64>8\"'9*%&!I-IW(5A
MZY&>D>4&7T @<C":)**@E#@&)%*.FQEA!))5+) 'U3FA)0=F'&JA!&8P9*"A
M'*J.$THB?H8"(2HV: F@ NJ'!6IQT4<J#WF*5ID _*-5E&@'B]589[D4$(F*
M&HIE.CJ5"_H%/GHEC;6B@!8](ND&O)6C.YJD2VI7,= %08IN4IH01<H↑5=JC
M/YJE3KIO/R22/R>+82I72OJC,J"E6HF3:8H'+&"D:\J@5\I8;UJFY3@%WO==
M"4""+J*9,-J'!%IA-'J@WY-QE36?5EI9Y9AQ1X$0L*2A:="A;)JG6Y &<$IE
M>#:ICV2I=2H32"JF3,JI?"HV?,D7A3J@?]B%%I-Q[T$6CFJJ6-JIPH9GL[J3
MHXJBF3JF>05F3TIE&9<&IBAY='JIOHJG/\JI6VJL"9JLO5JJOWJJP?IG681;
M?↑*=>AB@AOJJ-:H:(IE;8U"K;.J@6PH'Y/JER]J@'XJMD8J30YJCU,J@%/J@
M<8IN\\JN]=J@*BJLV>HDI,E[K2JCB J(PB:K>6BN]KH>\?H6>L*P_HJO1Y@\
MNK&'WSJC"'NF2R$&@D$1$EJM=H576↑JQ"TNG1MJNFHI7J4JL2S$&79JC*@NL
M6PJS4\JN,\ND9 JP#VL',;N3<S:)(JNGN/I#>.:S4\JK*=NOFKJG/$M/4C!<
M3- FZ <Y74(F+W M6.M?!L.)!7NH!@JE2R%W.2*<5,23,<"(C$JVS(B+DLBC
M;+HD#ZNU9;N<<,N@=-L&#VL0'TNO0FNO:-"W_2D9'A(5M4(F7PNNBFHQ8V '
M<\"VPDE;3" _252+*8 'NU%BNBB-,V&FV+.V5UNWA1A/;B(_AB@RB(B+5Q2P
MD;&5B:NQL&JC2[&5PFD797$&J1$4_O41MVBEB_6P<R P:>(C$NNX\#6X&DD'
M+P"3KWNPL2NN8VLU$FL&Z9:O%B$P_/JW7T"]+9NPL↑L3FI%D=IND L9*:+"E
MY1N↑V7NWE 6↑!M&]'(MN) FT[9J33+@↑↑6J_)8FRF,J@↑NL13UNQNP><S1NV
M+ILOR2FQ TRQWJLH9F &>":QY '!2S&X/X>'NA&N8↑*N<F A#'H1<N$"#/IC
MDN8"/\;!T6.O).+!7P#";R#"7T#"E6'";#"Q8L.*G;9(>?B\&[PD+.S",-Q<
M;F'":=#";@$Y:/)<SJ?!>)O$;7 C1AS"(YRW)FP&V↑O$8L.U *;#&;RXI *X
M?0O%0#S"_F7"8]"@@9N'+JH758?!\>7%W4A9>O'#;B#%,6Q=)EP9<BP'*;S'
MPBO&=?S"(XS'!$$'7R"\TH4&5EM@L,C%;]S'U$O'=HP'U*L75;R]<-#'Z6L0
M@#S)E2P'E[S)BAR(7_"_G2S(,?S)E_R_8J.9RRMV9.?&/(RGE27)J(P'D&?"
M=D!9\-7'>6K+09S+N$Q75↑*BR2G+3$Q9R0G,@YR<>:S,P-G'$XQGIQS$"_S,
MT[P48N-\UE4'?$&PI$$H#]/-K.I\>\!7D$ N\N@A+(#↑85&AK3#I-%7ZCR=
M&SR_[BQ*6LB$.9$1@$C/=I$@&!'((-!A↑36OIY, Y.P2,NP2>Y!?%↑Q\,!%,
M3:*CZ;S0R'S"#NK.OO@C#KJ*;M&*"F#1!(#12ZS1),+1 D$V]PK27DL:"= '
M&]S0.↑ 4&"W$#IU?.,PC2_P@)$VZ(S,01;PD↑1P9.TT7" W3,CW"1&W3>N'-
M#)VW!:W/4MW33D'/'.4F V'%>5O41N/$()#4/KW4J>S$-3W2-[V[#ZW/6NRU
M5CW2]"PF>'#&?)N'7NTOT]FU/-*W"4W6<SV=9ZW03\VJA4P7:]VZ; PM;TW2
M<JW'B.PC=↑VZC[TP/@W0';$2N8O7):=F>FQ=*BT9B8THC=S7,↑W93BT'4+W5
M<* 74TW55N/2/"W/E9W.4&)?'T')F'S79'.]9"8M(DW2"I.%N"W*=RT@;[ &
M87 0(J+9_↑6UM%(G=\(E @.(P(T&PFW%_WO7HK?/7*C4,_W)@7W3D-?:D4&H
MBQW7F3+,E777A%I9"4W/)BW/:K;+B_79A+I8I#W"D!?>@\W0"TS>Y)6<6?O?
MYWW1_8W,=#99"RP_44;5!P):L,T\LTT C?T%V4P'=WWAFJ(H!N(6[97?=YR<
M9TW/9.W"9RW33B";+* "DGO6+K)&;60>43$@ID(7GR4:"8:)L,OA5',G@_(C
M[OUQDE$&< 1I3/Q&C3I8501?Y($"9"5$.Y,"*Q".3.13*: "E=7D\4T1GOL]
MCDOD24ZJ66X&*'!)935$4D[E<*6+6,[D9"ZYK"L0F<CCGJ(5&I<3>8!@[LWA
MYW$'<Q$4[JW!8J H=\#+0N)02#0 @_588XX"< XZF_L"0"(D30[G@\O-1/Y(
MH(W:WXP7IR/.6V/2KY0IYZP \'W@'9'I1CY7_?;9_2;+HQY+Z$P MHO9<"$F
M<[7>↑DQ*\8Q(FC)":1'KIW/JG#XM.ZQ8.ML%GRWL↑$T:* Y60↑3B3M+>JIXI
M"PW.#P+JY8'17U[DI#[KW"[L*N"X7]#JNWYJ+D'MWB[KII[.DOL1Y&X&>%$&
M=_WJ\EX&JB$@2ID@%P'L'B'N#T+/[S[NDQ5GNGT2:23LH8<;'I<:32+PI\0$
M83U9P!K9U>X2S?X@,FWF4$X%TCXO#YX@-SX?U↑[IX2P>XWS@I4[/NZL"#E/N
M4_K99A#R\Q&SP↑[N$?\2+D\&T/R@,N;@;H @\P%+<K 3YW(Z,FT$26.!1O#Q
M H'N6B&EI3@Z[37=IP/U<G 6 ↑]E1+9B,Z;/138D88VCH&TPE4,:6*_U.6]P
M+F;P[XSP_X'0"\)@5X]J40\Q:[]F,Y;.!TWV<U\YHXWV=I_U&VYBS)9?&Z?I
M@F$7LR)"8V!">)$I&H04I.$B:5\@HE(NJN$>$"=AH27XG*CV↑J%?#G?7$QU:
MF,NA=1_Z>#_Z/P9+L=C@↑@S[(2(9>6!>E/\@:=_Z$L]I./DG<O;9&3="JH'0
M0IY;BA0>JW_W[]ZX:"EC(,#6=2YR .*Z?&[[N+_\A-_\CAO:T"_]>F+GU1_:
MVB_Z$M↑XD!MET1\9>;(G=\ZVY<_[_F('>0O]D' X._↑ "+5H,_\.=↑XAZ?↑
M↑=7↑XG\>;2W2N\_] XL7/\_↑T]\I%RLTYG$6QJ>)YS&P)J_[@V_↑\U↑;UEVB
MLL_↑T]\I%RLTYG$6QJ>)YU&;UATSNC_XYC__"_SS↑2_↑YS'S00_A2Y)"U77,
M_;_]_V\'J"?[[#_][__:H\WG9P'=DY:%_;_]_V\'W3D6O=?@[#_]=TZN74&P
MU]↑=8_'("K#[[YX:=T"[#<[↑U89@H'B'KMO_VY_SJ>'GL,P7/\_↑U89@H'B'
MJ\KNN__NJ7$'FOGS[%]M" :*=TBH_;_].9\:=]"W/\_6U89@H'B'?+VJ[+[[
M[YX:=Y GY5('GO_S[%]M" :*=Y@GY5('GN\?L,RJ_;_].9\:=R#O-RO[[%]M
M" :*=VA\:? G;J#I\CZE\?_NJ7$'C/3S;%UM" :*=_C6N__NN_:>X"9NLA\9
MIIF%(L!K<7&'B0]+<R "\?_N]28B↑-;@D6&:62@"=_ G D5J'.<2A"("\=_\
M)@3=97?7P\_2D ]IT#UI6=C_V___)@0HZ'8G/Q\9P\_2D ]I@()NT;W=E:\
M&@ :"%A30TA%344N3$Y+ %VA ]1"Q7H:ZW@ PO\( 8HX,+G3IRQ+P9
MPX5-&C%<QL!@X↑*-@5C10@&?.EVI0!T7',FS8DYY 1B;*C&3IAQ*1,
MXR8-G8P;.]*\J?--2HL8.\*1LS.EG#)AR*2<DZ?E'#-UW,3 R?%I5!DIVX2A
M@V:FUC,CV\R9<]",F9P>08I$↑S%DF8T$#2)4R- AQ)!U!A8\F'!APX=<M')E
MHU=NW[J Q[#9N%$#&@A84T-/32Y# $Q.2P!=C3D $42#)ZOP2R( ,+U2
MP#-GS)LV+L: : $B#(@Y:=K 85/FX1@T9=I4%).'3AF#9"H:E)B&HAP0*EXT
M4! PP9 W</+(27,T0*,:D !$C!PX<+$!P!$$DC)TT9$ T27,Q3!DV((24
MH:-G98(@;*!*H6ES#@@I9>:4D6.G#!FK4,:V23,'XALW(-B".",GC!N/2<V\
M.5G'C9RP=&:.P0O"S=L6(S7*&9,F#-0Z8A.D7+ER1!HW8]C4"0E"!,&+&<NX
M0".B\N7,FRMZGB,&I&C2E%D*A*BGXALS(%P+K6/&S%B4*A6,"&GF<L4A38)@
M24 #!J0!L0/F?DOG<ITPU=↑"H),'3EC@E8D;!S'DBY0B5*I(<9*@18SP98J[
M.?[%21$L5!*TEQ%=8)LP8\CQQG8#@C;&&B#H=9)#;(31AAAD,,C636N4D<<=
M>R4UF7#BS0="@P]&6&$>*."10@(HE+A3#SU\N,87,&7GAF,@\,$'3B:"P**+
M7_PU!QTI] ="&7AX),>,4-D1QDQAB$&15QL2:21<3%@1!!,\QIC&6XZQP,:+
M/M+!0F!UE+&#D&R\,0:-2C+IY'<;_H@=4R!4>65<;NBU@W[2C01'2;]=IA=X
M"JS4YQN<B<&;;R?%2<><"O4%T1GS)=7426,HVML6R"G7Q9[2B1&&6"#<-EVB
MB_[F**1XWI3IJ&8F\%RHL":X5VYUR/'770GV-=B6<*U:G4*7N0I'8'O.*I!N
MFC(* AQO%*MJ<(8*I. =2R854F9+SOD6E,$5"P(9;WS181DHI, "N5↑(14>Z
MZY8;1QUO> 0ONR!"&,:]Y1KD1EN!E>$@O↑8↑%0:)*9RI@+CX3D4P10&/\?!4
M<LI!L+]D$&Q7QNJRNU>Z"C-<;AIF$"Q&&6=<1O =: "J\1ACA#4'R"O9B>5_
M%7[A&HQBJ/'1NPD+*2U=35+4*V8R;E=T11MRYQUQ#Y$Y& A[Y(;&DBC=]<6,
M&NW0:F%TZ(QH&2QHO>09<WC=!PA.4$%$$48H+.>P;+L-=];'RE'VHV)LT86.
M5%LE0A!4/-&$""S(.L 34'Q!N.&)Q\""X$5$\0/BBC/↑1>6))R##Y HD(((3
M53#!Q.6=:TZZZ9&#+KH33U"!↑7.JE\Y$ZX(/\8034\R↑>..Z\Y[XY[D'(87O
MF@]A?.>2YT[$\8G3#OSSS+LNPA3HM:"\%"%@GH#FV%.Q_?#6AZ_]\]VGWGCX
M0U#ON?4K(-]X$$00T7D+Q(<N0@OR?S%%%4*X7_Y$IX+↑-:%T K1>%*H0NR04
MH6W>T]P"GY! P?&@?TR8PA0JJ+\>]*]RM],/_JSG@_X=@0I2X& "8+"2/BBL
M6@_Q#F-HI* V*.U-A'*:6>(3-3G486I5NQ1*S! VKIGI:RA0 1&_8(8QN"$%
M( /!VHQ@M[BM9&YTHN+;C##$O+& B$WR&↑#V(+@)4J$(F&/7O.I%-L$Q(0A-
M$ (1@I#&<N4K0M9[VQNS4,>"-2@/UF,">KS7,#&Y$3T%[%PA*Q9(])QG"'V$
MV%_&D$>X)<$↑?3Q7↑="3/OVPRUW62X(1"#DR,U@O>$0@I=C<0 ;K":$(1[AD
M'T↑6,C=L<H$/' (:$\<N6E[&>D%P0BH56:Z-6>\)T/-DN?9BO2L@(0
∂31-Aug-89 0542 ramsdell@linus.mitre.org Re: Multiple values for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 31 Aug 89 05:42:24 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02306; Thu, 31 Aug 89 08:20:06 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA26653; Thu, 31 Aug 89 08:20:36 EDT
Posted-Date: Thu, 31 Aug 89 08:13:52 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA03764; Thu, 31 Aug 89 08:13:53 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908311213.AA03764@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: Re: Multiple values for R4RS
In-Reply-To: Your message of Wed, 30 Aug 89 16:56:19 -0500.
<8908302155.AA07362@life.ai.mit.edu>
Date: Thu, 31 Aug 89 08:13:52 EDT
>> From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
...
>> I now see that there is some value in requiring "(values e)" to be the
>> same as "e", even in the absense of the infamous "truncation" feature.
>> There is also some value in requiring (or allowing) "(values e)" to be
>> distinct from "e". I see the latter as simpler, not more eomplex, both
>> in terms of the semantics and in terms of the implementation. However,
>> as I said at Snowbird, I am willing to defer to the judgement of the
>> majority on this issue.
>>
>> Kent
This confirms my hope that there is good chance we can reach agreement
on the subject of multiple values for R4RS. Let me point out that if
agreement is reached soon enough, multiple values could be made part
of IEEE Draft Standard for the Scheme Programming Language.
Before I submit the proposal, I ask for editorial suggestions,
especially to the sentence:
Within procedure 'generator', the initial escape procedure returned
by call-with-current-continuation is like 'receiver' except that
this escape procedure's continuation is the one that was in effect
when the evaluation of the with-values expression began (see
call-with-current-continuation).
How about this?
When procedure 'generator' is called, capturing its initial continuation
with call-with-current-continuation produces an escape procedure which
is like 'receiver' except that this escape procedure's continuation
is the one that was in effect when the evaluation of the with-values
expression began (see call-with-current-continuation).
Here is attempt at the changes required in
call-with-current-continuation.
Replace the last sentence in the first paragraph with:
The escape procedure is a Scheme procedure which when called, will
ignore whatever continuation is in effect at that later time and will
give its arguments to the continuation that was in effect when the
escape procedure was created. Within a with-values expression, the
arity of the escape procedure which packages the continuation in
effect when the generator is called must match that of the receiver.
All other escape procedures must accept at least one argument. Some
implementions may choose to ignore extra arguments, others may signal
an error when more then one argument is given.
John
∂31-Aug-89 1103 ramsdell@linus.mitre.org Multiple values not for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 31 Aug 89 11:02:47 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA04321; Thu, 31 Aug 89 13:08:03 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA00180; Thu, 31 Aug 89 13:09:00 EDT
Posted-Date: Thu, 31 Aug 89 13:02:15 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA04528; Thu, 31 Aug 89 13:02:17 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908311702.AA04528@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Multiple values not for R4RS
In-Reply-To: Your message of Thu, 31 Aug 89 09:20:53 -0700.
<8908311620.AA26072@Polya.Stanford.EDU>
Date: Thu, 31 Aug 89 13:02:15 EDT
Well I guess now the focus is to generate a proposal in preparation
for the next Scheme meeting. Hopefully, the proposal presented at the
meeting will have been agreed to by those reachable by E-mail. It
sounds like those interested in records are following the same plan.
R4RS just is not going to have multiple values. Let's make sure R5RS
does.
>> From: Morris J. Katz <katz@Polya.Stanford.EDU>
...
>> The escape procedure is a Scheme procedure which when applied to a
>> value(s) will ignore whatever continuation is in effect at the time of
>> application and will instead give its argument(s) to the continuation
>> that was in effect when the escape procedure was created. The arity
>> of an escape procedure created in the 'generator' position of a
>> 'with-values' form must match that of the 'receiver'. All other
>> escape procedures must accept at least one argument. Some
>> implementions may choose to ignore extra arguments, others may signal
>> an error when more then one argument is given.
...
Morry, I think your wording is better than my attempt, but how about
this small modification?
The escape procedure is a Scheme procedure which when applied to some
values will ignore whatever continuation is in effect at the time of
application and will instead give its arguments to the continuation
that was in effect when the escape procedure was created. The arity
of an escape procedure created in the 'generator' position of a
'with-values' form must match that of the 'receiver'. All other
escape procedures must accept at least one argument. Some
implementions may choose to ignore extra arguments, others may signal
an error when more then one argument is given.
I am not happy with Morry's rewording of the description of
with-values. Any more suggestions?
John
PS. The intended formal description of with-values is:
%%% Raw TeX.
$$\hbox{\it with-values} = \hbox{\it twoarg }(\lambda \epsilon_1
\epsilon_2\kappa . \hbox{ \it applicate } \epsilon_1 \langle \rangle
\lambda \epsilon↑\star . \hbox{ \it applicate } \epsilon_2
\epsilon↑\star \kappa)$$
\end
∂31-Aug-89 1106 dyb@iuvax.cs.indiana.edu Re: Multiple values for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 31 Aug 89 11:06:21 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04445; Thu, 31 Aug 89 13:24:58 EDT
Message-Id: <8908311724.AA04445@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Thu, 31 Aug 89 10:11:18 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: ramsdell@linus.mitre.org, rrrs-authors@life.ai.mit.edu
Subject: Re: Multiple values for R4RS
> From ramsdell@linus.mitre.org Thu Aug 31 07:35:26 1989
> Subject: Re: Multiple values for R4RS
>
> This confirms my hope that there is good chance we can reach agreement
> on the subject of multiple values for R4RS. Let me point out that if
> agreement is reached soon enough, multiple values could be made part
> of IEEE Draft Standard for the Scheme Programming Language.
I don't see how. We agreed at Snowbird not to make any significant
changes to R4RS via email that weren't preapproved at Snowbird, and we
specifically left multiple values as an issue to be decided at the next
meeting. So multiple values must wait until R5RS or we must delay R4RS
until after we meet again. Either way, multiple values won't make the
IEEE draft standard, right?
∂31-Aug-89 1111 katz@polya.stanford.edu Multiple values for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 31 Aug 89 11:11:07 PDT
Received: from Polya.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA04411; Thu, 31 Aug 89 13:22:30 EDT
Received: by Polya.Stanford.EDU (5.61/25-eef) id AA26072; Thu, 31 Aug 89 09:20:53 -0700
Date: Thu, 31 Aug 89 09:20:53 -0700
From: Morris J. Katz <katz@polya.stanford.edu>
Message-Id: <8908311620.AA26072@Polya.Stanford.EDU>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: ramsdell@linus.mitre.org's message of Thu, 31 Aug 89 08:13:52 EDT <8908311213.AA03764@huxley.mitre.org>
Subject: Multiple values for R4RS
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Posted-Date: Thu, 31 Aug 89 08:13:52 EDT
From: ramsdell@linus.mitre.org
Date: Thu, 31 Aug 89 08:13:52 EDT
Here is attempt at the changes required in
call-with-current-continuation.
Replace the last sentence in the first paragraph with:
The escape procedure is a Scheme procedure which when called, will
ignore whatever continuation is in effect at that later time and will
give its arguments to the continuation that was in effect when the
escape procedure was created. Within a with-values expression, the
arity of the escape procedure which packages the continuation in
effect when the generator is called must match that of the receiver.
All other escape procedures must accept at least one argument. Some
implementions may choose to ignore extra arguments, others may signal
an error when more then one argument is given.
Once again I will try my hand at an alternative set of prose.
The escape procedure is a Scheme procedure which when applied to a
value(s) will ignore whatever continuation is in effect at the time of
application and will instead give its argument(s) to the continuation
that was in effect when the escape procedure was created. The arity
of an escape procedure created in the 'generator' position of a
'with-values' form must match that of the 'receiver'. All other
escape procedures must accept at least one argument. Some
implementions may choose to ignore extra arguments, others may signal
an error when more then one argument is given.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂31-Aug-89 1121 ramsdell@linus.mitre.org Re: Multiple values for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 31 Aug 89 11:20:51 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA03732; Thu, 31 Aug 89 11:47:31 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA29266; Thu, 31 Aug 89 11:48:30 EDT
Posted-Date: Thu, 31 Aug 89 11:41:45 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA04414; Thu, 31 Aug 89 11:41:47 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908311541.AA04414@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: Re: Multiple values for R4RS
In-Reply-To: Your message of Thu, 31 Aug 89 10:11:18 -0500.
<8908311511.AA28731@linus.MITRE.ORG>
Date: Thu, 31 Aug 89 11:41:45 EDT
>> From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
>>
>> > From ramsdell@linus.mitre.org Thu Aug 31 07:35:26 1989
>> > Subject: Re: Multiple values for R4RS
>> >
>> > This confirms my hope that there is good chance we can reach agreement
>> > on the subject of multiple values for R4RS. Let me point out that if
>> > agreement is reached soon enough, multiple values could be made part
>> > of IEEE Draft Standard for the Scheme Programming Language.
>>
>> I don't see how. We agreed at Snowbird not to make any significant
>> changes to R4RS via email that weren't preapproved at Snowbird, and we
>> specifically left multiple values as an issue to be decided at the next
>> meeting. So multiple values must wait until R5RS or we must delay R4RS
>> until after we meet again. Either way, multiple values won't make the
>> IEEE draft standard, right?
At the very least, we can prepare a proposal for the next meeting
which is agreeable to all reachable by E-mail. It seems too bad no
action can be taken on a subject on which there seems to be near
agreement. Is that what you really want?
John
PS. In case my words are describing WITH-VALUES are confusing, here
is a formal description of my intended semantics.
%%% Raw TeX.
$$\hbox{\it with-values} = \hbox{\it twoarg }(\lambda \epsilon_1
\epsilon_2\kappa . \hbox{ \it applicate } \epsilon_1 \langle \rangle
\lambda \epsilon↑\star . \hbox{ \it applicate } \epsilon_2
\epsilon↑\star \kappa)$$
\end
∂31-Aug-89 1134 katz@polya.stanford.edu Revised multiple values and call/cc.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 31 Aug 89 11:33:47 PDT
Received: from Polya.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA04621; Thu, 31 Aug 89 13:33:23 EDT
Received: by Polya.Stanford.EDU (5.61/25-eef) id AA25497; Thu, 31 Aug 89 09:01:12 -0700
Date: Thu, 31 Aug 89 09:01:12 -0700
From: Morris J. Katz <katz@polya.stanford.edu>
Message-Id: <8908311601.AA25497@Polya.Stanford.EDU>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Wed, 30 Aug 89 15:39:08 EDT <8908301939.AA02909@huxley.mitre.org>
Subject: Revised multiple values and call/cc.
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Posted-Date: Wed, 30 Aug 89 15:39:08 EDT
From: ramsdell@linus.mitre.org
Date: Wed, 30 Aug 89 15:39:08 EDT
Let me revise the proposal by substituting
Within procedure 'generator', the initial escape procedure returned
by call-with-current-continuation is like 'receiver' except that
this escape procedure's continuation is the one that was in effect
when the evaluation of the with-values expression began (see
call-with-current-continuation).
for
Within procedure 'generator', the initial escape procedure returned
by call-with-current-continuation is 'receiver'.
I find the new proposed wording somewhat opaque and have therefore
tried my hand at prose as well.
During the evaluation of a 'with-values' form, the 'generator' thunk
is first thawed (evaluated to yield some values) and then the 'receiver' is
applied to the values returned by 'generator'. This means that a
continuation captured in 'generator' includes the application of
'receiver' to the values returned by 'generator'. It also includes the
return from 'with-values' of the value(s) returned by 'receiver'.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂31-Aug-89 2019 @spencer.cs.uoregon.edu:will@cs.uoregon.edu Re: Multiple values not for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 31 Aug 89 20:19:12 PDT
Received: from skinner.cs.uoregon.edu by life.ai.mit.edu (4.1/AI-4.10) id AA10140; Thu, 31 Aug 89 22:58:47 EDT
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA29911; Thu, 31 Aug 89 15:10:16 PDT
Received: by spencer.cs.uoregon.edu; Thu, 31 Aug 89 15:10:00 PDT
Date: Thu, 31 Aug 89 15:10:00 PDT
From: will@cs.uoregon.edu
Message-Id: <8908312210.AA04962@spencer.cs.uoregon.edu>
To: rrrs-authors@life.ai.mit.edu
Subject: Re: Multiple values not for R4RS
Cc: ramsdell@linus.mitre.org
You shouldn't have to worry so much about the wording, since that can
be left to whoever edits the R5RS.
Congratulations: you have reached consensus on multiple values. Now
all you have to do is to maintain that consensus until the next meeting
and to agree on the name of WITH-VALUES, RECEIVE-VALUES, CALL-WITH-VALUES,
whatever.
Summary of consensus: the VALUES procedure takes any number of arguments,
and simply passes them to its continuation. A procedure to be named
later takes a thunk and a procedure, and calls the thunk with a
continuation that, when passed some values, calls the procedure that
was the second argument to the procedure to be named later with those
values as arguments. Except for continuations created by the procedure
to be named later, all continuations take exactly one value, as now;
the effect of passing no value or more than one value to continuations
that were not created by the procedure to be named later is unspecified
(as indeed it is unspecified now).
Peace, Will
∂31-Aug-89 2026 katz@polya.stanford.edu Multiple values not for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 31 Aug 89 20:26:14 PDT
Received: from Polya.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA10285; Thu, 31 Aug 89 23:05:30 EDT
Received: by Polya.Stanford.EDU (5.61/25-eef) id AA05748; Thu, 31 Aug 89 13:17:44 -0700
Date: Thu, 31 Aug 89 13:17:44 -0700
From: Morris J. Katz <katz@polya.stanford.edu>
Message-Id: <8908312017.AA05748@Polya.Stanford.EDU>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Thu, 31 Aug 89 13:02:15 EDT <8908311702.AA04528@huxley.mitre.org>
Subject: Multiple values not for R4RS
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Posted-Date: Thu, 31 Aug 89 13:02:15 EDT
From: ramsdell@linus.mitre.org
Date: Thu, 31 Aug 89 13:02:15 EDT
Morry, I think your wording is better than my attempt, but how about
this small modification?
I only used the phraseology "value(s)" for pedantic reasons. If
people generally feel that the implications are obvious without being
quite as pedantic, I am perfectly happy with your reworking of my
wording.
I am not happy with Morry's rewording of the description of
with-values. Any more suggestions?
If it is possible, I would be interested in what about my wording you
find troubling. (I realize that often bad feelings about wordings are
based on gut level feelings that are hard to explain.) Given some
input, I would be happy to work on refining my prose.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂01-Sep-89 0001 Pavel.pa@xerox.com An alternate description of the multiple values proposal
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 00:00:36 PDT
Received: from Xerox.COM by life.ai.mit.edu (4.1/AI-4.10) id AA00226; Fri, 1 Sep 89 02:52:08 EDT
Received: from Salvador.ms by ArpaGateway.ms ; 31 AUG 89 12:51:32 PDT
Date: Thu, 31 Aug 89 12:51:32 PDT
From: Pavel.pa@xerox.com
Subject: An alternate description of the multiple values proposal
To: rrrs-authors@life.ai.mit.edu
Cc: Pavel.pa@xerox.com
Message-Id: <890831-125133-8085@Xerox>
As I said in my last message on this topic, I'm pretty unsatisfied with the
descriptions that have been circulated thus far. Unfortunately, my
proposed description in that message seems to have been ignored, so I'll
repeat it here in the context of a complete proposed description of the
facility, including the write-ups of VALUES, CALL-WITH-VALUES, and
CALL-WITH-CURRENT-CONTINUATION.
I like this wording much more than the others presented so far because it
seems much clearer to me. The others have all been too vague or opaque for
my taste; in particular, none of them say anything about the legality of
returning other than one value to ``for effect'' context. Some of the
earlier descriptions also use the wording ``a `with-values' form'' or ``a
`with-values' expression''; this is misleading, since WITH-VALUES (or
CALL-WITH-VALUES) is a procedure, not a syntactic keyword.
I would appreciate hearing any comments on the description below.
Pavel
====================
(VALUES obj ...) [Procedure]
Returns all of the arguments, in the order given. VALUES could be
implemented as follows:
(define values
(lambda args
(call-with-current-continuation
(lambda (k)
(apply k args)))))
See the description of CALL-WITH-CURRENT-CONTINUATION for a discussion of
the number of values accepted by various contexts.
(CALL-WITH-VALUES producer consumer) [Procedure]
Producer should be a procedure of zero arguments and consumer should be a
procedure. Consumer is applied to the value(s) returned by invoking
producer. CALL-WITH-VALUES returns the result(s) of the invocation of
consumer.
(CALL-WITH-CURRENT-CONTINUATION proc) [Procedure]
Proc must be a procedure of one argument. The procedure
CALL-WITH-CURRENT-CONTINUATION packages up the current continuation as an
``escape procedure'' and passes it as an argument to proc. The escape
procedure is a Scheme procedure that when applied, ignores the continuation
in effect at that time and instead gives its argument(s) to the
continuation that was in effect when the escape procedure was created.
The number of arguments accepted by an escape procedure depends upon the
continuation in effect when the escape procedure was created. There are
six contexts in which continuations can be captured in Scheme:
1. the operator position of a procedure call,
2. an operand position of a procedure call,
3. the test position of a conditional,
4. the expression in an assignment,
5. any but the last expression in the body of a lambda expression, and
6. the invocation of the producer argument to CALL-WITH-VALUES.
Escape procedures created in any of the first four contexts accept at least
one argument; the effect of applying them to more than one value is
unspecified. In some implementations, an error is signalled; in some
others, the extra values are ignored.
Escape procedures created in the fifth context above ignore any arguments
passed to them and so accept any number of values, including zero.
An escape procedure created in the final context above accepts exactly as
many arguments as are accepted by the consumer procedure in that invocation
of CALL-WITH-VALUES.
∂01-Sep-89 0052 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu Programmer-defined data types, version 2
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 00:52:09 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00439; Fri, 1 Sep 89 03:43:12 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03329;
31 Aug 89 15:55 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 31 Aug 89 15:55:39 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa02540;
31 Aug 89 14:47 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA05616; Thu, 31 Aug 89 14:45:51 EDT
Received: from localhost by zurich.ai.mit.edu; Thu, 31 Aug 89 14:42:33 edt
Date: Thu, 31 Aug 89 14:42:33 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8908311842.AA05074@zurich.ai.mit.edu>
To: katz@polya.stanford.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: "Morris J. Katz"'s message of Wed, 30 Aug 89 12:02:13 -0700 <8908301902.AA20609@Polya.Stanford.EDU>
Subject: Programmer-defined data types, version 2
Date: Wed, 30 Aug 89 12:02:13 -0700
From: "Morris J. Katz" <katz@polya.stanford.edu>
For aesthetic reasons I would prefer to see
(MAKE-RECORD-TYPE type-name . field-names)
rather than
(MAKE-RECORD-TYPE type-name field-names)
as the for for MAKE-RECORD-TYPE.
How do others feel?
I prefer having a single argument which is a list. Not only does this
reduce the number of characters that must be typed, but it simplifies
abstraction on the `field-names' argument, and leaves the argument
list open for adding arguments in the future.
∂01-Sep-89 0054 @mc.lcs.mit.edu,@life.ai.mit.edu:jar@zurich.ai.mit.edu Programmer-defined data types, version 2
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 00:54:24 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00440; Fri, 1 Sep 89 03:44:33 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07773;
31 Aug 89 22:04 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 31 Aug 89 22:04:23 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07614;
31 Aug 89 21:48 EDT
Received: from zurich.ai.mit.edu ([18.43.0.158]) by life.ai.mit.edu (4.1/AI-4.10) id AA09401; Thu, 31 Aug 89 21:46:38 EDT
Received: from localhost by zurich.ai.mit.edu; Thu, 31 Aug 89 21:43:24 edt
Date: Thu, 31 Aug 89 21:43:24 edt
From: Jonathan Rees <jar@zurich.ai.mit.edu>
Message-Id: <8909010143.AA19695@zurich.ai.mit.edu>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Tue, 29 Aug 89 18:29:19 PDT <890829-184715-4408@Xerox>
Subject: Programmer-defined data types, version 2
I endorse version 2 and all your replies to everyone, with one very
minor nit: allowing RECORD-TYPE-FIELD-NAMES to return a permutation of
the original argument to MAKE-RECORD-TYPE feels inconsistent with
making optional the list-of-field-names argument to
MAKE-RECORD-CONSTRUCTOR. The original ordering of the list must be
remembered, in case someone omits the argument to
MAKE-RECORD-CONSTRUCTOR, so why should a Scheme system gratuitously
refuse to cough it up? The order might be of some interest to, say, a
portable inspector. But I don't feel at all strongly about this.
Jonathan
∂01-Sep-89 0259 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu Programmer-defined data types, version 2
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 02:59:07 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01182; Fri, 1 Sep 89 05:49:55 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06292;
31 Aug 89 20:03 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 31 Aug 89 20:03:47 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa05061;
31 Aug 89 18:20 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA07566; Thu, 31 Aug 89 18:19:03 EDT
Received: from localhost by zurich.ai.mit.edu; Thu, 31 Aug 89 18:15:50 edt
Date: Thu, 31 Aug 89 18:15:50 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8908312215.AA07597@zurich.ai.mit.edu>
To: katz@polya.stanford.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Morris J. Katz's message of Thu, 31 Aug 89 13:26:10 -0700 <8908312026.AA06068@Polya.Stanford.EDU>
Subject: Programmer-defined data types, version 2
Date: Thu, 31 Aug 89 13:26:10 -0700
From: Morris J. Katz <katz@Polya.Stanford.EDU>
Date: Thu, 31 Aug 89 14:42:33 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Date: Wed, 30 Aug 89 12:02:13 -0700
From: "Morris J. Katz" <katz@polya.stanford.edu>
For aesthetic reasons I would prefer to see
(MAKE-RECORD-TYPE type-name . field-names)
rather than
(MAKE-RECORD-TYPE type-name field-names)
as the for for MAKE-RECORD-TYPE.
How do others feel?
I prefer having a single argument which is a list. Not only does this
reduce the number of characters that must be typed, but it simplifies
abstraction on the `field-names' argument, and leaves the argument
list open for adding arguments in the future.
I might be swayed that it is important to leave the rest argument
position open for future extensions; but, I hardly buy that the
trade-off between 3 characters to form the list and one character per
symbol to make it into a symbol represents enough of a difference in
keystrokes to be important. (My approach is actually shorter for
records of 1 or 2 fields (-:)
Since I was obviously making an aesthetic argument, let's just
summarize by saying I prefer the aesthetics of a single list argument.
(I notice that you said nothing about my "abstraction" argument.)
∂01-Sep-89 0304 @mc.lcs.mit.edu,@life.ai.mit.edu:katz@polya.stanford.edu Programmer-defined data types, version 2
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 03:04:06 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01223; Fri, 1 Sep 89 05:54:31 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09165;
1 Sep 89 0:01 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Sep 89 00:01:30 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09029;
31 Aug 89 23:57 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07442; Thu, 31 Aug 89 18:12:19 EDT
Received: from Polya.Stanford.EDU (polya.stanford.edu) by zurich.ai.mit.edu; Thu, 31 Aug 89 17:52:09 edt
Received: by Polya.Stanford.EDU (5.61/25-eef) id AA06068; Thu, 31 Aug 89 13:26:10 -0700
Date: Thu, 31 Aug 89 13:26:10 -0700
From: "Morris J. Katz" <katz@polya.stanford.edu>
Message-Id: <8908312026.AA06068@Polya.Stanford.EDU>
To: cph@zurich.ai.mit.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Chris Hanson's message of Thu, 31 Aug 89 14:42:33 edt <8908311842.AA05074@zurich.ai.mit.edu>
Subject: Programmer-defined data types, version 2
Date: Thu, 31 Aug 89 14:42:33 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Date: Wed, 30 Aug 89 12:02:13 -0700
From: "Morris J. Katz" <katz@polya.stanford.edu>
For aesthetic reasons I would prefer to see
(MAKE-RECORD-TYPE type-name . field-names)
rather than
(MAKE-RECORD-TYPE type-name field-names)
as the for for MAKE-RECORD-TYPE.
How do others feel?
I prefer having a single argument which is a list. Not only does this
reduce the number of characters that must be typed, but it simplifies
abstraction on the `field-names' argument, and leaves the argument
list open for adding arguments in the future.
I might be swayed that it is important to leave the rest argument
position open for future extensions; but, I hardly buy that the
trade-off between 3 characters to form the list and one character per
symbol to make it into a symbol represents enough of a difference in
keystrokes to be important. (My approach is actually shorter for
records of 1 or 2 fields (-:)
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂01-Sep-89 0333 jinx@zurich.ai.mit.edu An alternate description of the multiple values proposal
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 03:33:37 PDT
Received: from zurich.ai.mit.edu ([18.43.0.171]) by life.ai.mit.edu (4.1/AI-4.10) id AA01454; Fri, 1 Sep 89 06:26:25 EDT
Received: from localhost by zurich.ai.mit.edu; Fri, 1 Sep 89 06:23:14 edt
Date: Fri, 1 Sep 89 06:23:14 edt
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <8909011023.AA11008@zurich.ai.mit.edu>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@life.ai.mit.edu, Pavel.pa@xerox.com
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 31 Aug 89 12:51:32 PDT <890831-125133-8085@Xerox>
Subject: An alternate description of the multiple values proposal
I'm happy with your wording. There is one minor thing however:
(CALL-WITH-VALUES producer consumer) [Procedure]
Producer should be a procedure of zero arguments and consumer should be a
procedure. Consumer is applied to the value(s) returned by invoking
producer. CALL-WITH-VALUES returns the result(s) of the invocation of
consumer.
Producer does not have to be a procedure of exactly zero arguments.
There is no reason to outlaw procedures of zero or more arguments. On
the other hand, I don't feel at all strongly about this.
Perhaps "Producer should be a procedure that accepts zero arguments
and consumer should be a procedure..." would be better.
∂01-Sep-89 0544 ramsdell@linus.mitre.org Please rename BABY-DOE and agree on an agenda item
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 05:44:31 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02732; Fri, 1 Sep 89 08:33:10 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA21036; Fri, 1 Sep 89 08:34:06 EDT
Posted-Date: Fri, 01 Sep 89 08:27:22 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA05535; Fri, 1 Sep 89 08:27:23 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8909011227.AA05535@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: Please rename BABY-DOE and agree on an agenda item
In-Reply-To: Your message of Thu, 31 Aug 89 15:10:00 -0700.
<8908312210.AA04962@spencer.cs.uoregon.edu>
Date: Fri, 01 Sep 89 08:27:22 EDT
>> From: will@cs.uoregon.edu
....
>> Summary of consensus: the VALUES procedure takes any number of arguments,
>> and simply passes them to its continuation. A procedure to be named
>> later takes a thunk and a procedure, and calls the thunk with a
>> continuation that, when passed some values, calls the procedure that
>> was the second argument to the procedure to be named later with those
>> values as arguments. Except for continuations created by the procedure
>> to be named later, all continuations take exactly one value, as now;
>> the effect of passing no value or more than one value to continuations
>> that were not created by the procedure to be named later is unspecified
>> (as indeed it is unspecified now).
This is an excellent summary of the consensus in my opinion.
>> You shouldn't have to worry so much about the wording, since that can
>> be left to whoever edits the R5RS.
Your wording of the consensus sounds like an excellent basis for a
wording of the proposal, however, I agree we should not worry about
the precise wording. Remember the R5RS editors most likely will
change whatever wording we generate. I would like to end up with some
agreed upon text that we can put on a meeting agenda. The text does
not have to be text for R5RS, but can be directions to the editor.
Let BABY-DOE be the name of the procedure which creates continuations
accepting multiple values. What do you think about this as a meeting
agenda item?
------------------------
The editors are directed to add text to R5RS so as to include the
procedures VALUES and BABY-DOE consistant with the following
definitions. The VALUES procedure takes any number of arguments, and
simply passes them to its continuation. The BABY-DOE procedure takes
a thunk and a procedure, and calls the thunk with a continuation that,
when passed some values, calls the procedure that was the second
argument to the BABY-DOE procedure with those values as arguments.
Except for continuations created by the BABY-DOE procedure, all
continuations take exactly one value, as now; the effect of passing no
value or more than one value to continuations that were not created by
the BABY-DOE procedure is unspecified (as indeed it is unspecified
now).
------------------------
I would like to separate the discussion on multiple values into the
two topics of naming BABY-DOE and agreeing upon the agenda item. I am
not against using actual R5RS text as the basis for an agenda item.
John
∂01-Sep-89 0610 ramsdell@linus.mitre.org Re: Multiple values not for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 06:10:08 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02974; Fri, 1 Sep 89 08:54:42 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA21245; Fri, 1 Sep 89 08:55:21 EDT
Posted-Date: Fri, 01 Sep 89 08:48:37 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA05551; Fri, 1 Sep 89 08:48:39 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8909011248.AA05551@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: Re: Multiple values not for R4RS
In-Reply-To: Your message of Thu, 31 Aug 89 13:17:44 -0700.
<8908312017.AA05748@Polya.Stanford.EDU>
Date: Fri, 01 Sep 89 08:48:37 EDT
>> From: Morris J. Katz <katz@Polya.Stanford.EDU>
...
>> If it is possible, I would be interested in what about my wording you
>> find troubling. (I realize that often bad feelings about wordings are
>> based on gut level feelings that are hard to explain.) Given some
>> input, I would be happy to work on refining my prose.
Sorry about that. I did not mean to be so gruff in my reply.
>> During the evaluation of a 'with-values' form, the 'generator' thunk
>> is first thawed (evaluated to yield some values) and then the 'receiver' is
>> applied to the values returned by 'generator'. This means that a
>> continuation captured in 'generator' includes the application of
>> 'receiver' to the values returned by 'generator'. It also includes the
>> return from 'with-values' of the value(s) returned by 'receiver'.
The problem I see with this text is that the continuation captured in
'generator' may not be the one your text suggests. Consider
(baby-doe
(lambda ()
(let ((x (call-with-current-continuation
(lambda (c) ...))))
....))
...)
One other point (a small nit I admit), is I prefer the phrase "the
'generator' is called to yield some values" to "the 'generator' is
first thawed (evaluated to yield some values)" but this is what
editors are for.
∂01-Sep-89 0623 ramsdell@linus.mitre.org Re: An alternate description of the multiple values proposal
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 06:23:28 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA03116; Fri, 1 Sep 89 09:14:50 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA21412; Fri, 1 Sep 89 09:15:29 EDT
Posted-Date: Fri, 01 Sep 89 09:08:45 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA05558; Fri, 1 Sep 89 09:08:46 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8909011308.AA05558@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: Re: An alternate description of the multiple values proposal
In-Reply-To: Your message of Thu, 31 Aug 89 12:51:32 -0700.
<890831-125133-8085@Xerox>
Date: Fri, 01 Sep 89 09:08:45 EDT
>> From: Pavel.pa@xerox.com
...
>> As I said in my last message on this topic, I'm pretty unsatisfied with the
>> descriptions that have been circulated thus far. Unfortunately, my
>> proposed description in that message seems to have been ignored, so I'll
>> repeat it here in the context of a complete proposed description of the
>> facility, including the write-ups of VALUES, CALL-WITH-VALUES, and
>> CALL-WITH-CURRENT-CONTINUATION.
Pavel, I thought I was responding to your concerns by changing my
description of VALUES so as not to special case the single-argument
case.
As to your current proposal, I think it has some strengths and
weaknesses. I like the terminology of producer/consumer better than
generator/receiver. The text describing
CALL-WITH-CURRENT-CONTINUATION also looks good. I think that the
BABY-DOE procedure should include text that makes it clear what
happens when the continuation given to the producer is captured by
CALL-WITH-CURRENT-CONTINUATION.
On naming BABY-DOE, I think we can assume that Pavel suggests
CALL-WITH-VALUES and Chris Hanson suggests WITH-VALUES.
John
∂01-Sep-89 0757 ramsdell@linus.mitre.org An alternative to ACCEPTS?
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 07:57:11 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA03858; Fri, 1 Sep 89 10:47:42 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA22816; Fri, 1 Sep 89 10:48:42 EDT
Posted-Date: Fri, 01 Sep 89 10:41:58 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA05581; Fri, 1 Sep 89 10:41:59 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8909011441.AA05581@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: An alternative to ACCEPTS?
In-Reply-To: Your message of Tue, 22 Aug 89 13:16:43 -0700.
<8908222017.AA22154@sde.hp.com>
Date: Fri, 01 Sep 89 10:41:58 EDT
[This is not part of the multiple values compromise.]
As an alternative to providing ACCEPTS?, maybe we should simply
provide a way of generating truncating continuations. Suppose we
provided a procedure like CALL-WITH-CURRENT-CONTINUATION, except that
if the escape procedure generated by CALL-WITH-CURRENT-CONTINUATION
accepts exactly n arguments, the new procedure generates an escape
procedure which will accept n or more arguments, and ignore the extra
ones. The advantage of this approach is that implementations are only
required to be able to compute the arity of escape procedures, not all
procedures. Here is an example of its use:
(define (quotient-and-maybe-remainder n1 n2)
(call-with-truncating-continuation
(lambda (k)
(let* ((q (quotient n1 n2))
(r (- n1 (* q n2))))
(k q r)))))
(quotient-and-maybe-remainder 1 1) => 1
John
∂01-Sep-89 0900 @mc.lcs.mit.edu,@life.ai.mit.edu:katz@polya.stanford.edu Programmer-defined data types, version 2
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 09:00:17 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04647; Fri, 1 Sep 89 11:50:28 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16650;
1 Sep 89 11:44 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Sep 89 11:44:47 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa16623;
1 Sep 89 11:42 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04521; Fri, 1 Sep 89 11:42:53 EDT
Received: from Polya.Stanford.EDU (polya.stanford.edu) by zurich.ai.mit.edu; Fri, 1 Sep 89 11:39:35 edt
Received: by Polya.Stanford.EDU (5.61/25-eef) id AA04825; Fri, 1 Sep 89 08:42:07 -0700
Date: Fri, 1 Sep 89 08:42:07 -0700
From: "Morris J. Katz" <katz@polya.stanford.edu>
Message-Id: <8909011542.AA04825@Polya.Stanford.EDU>
To: cph@zurich.ai.mit.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Chris Hanson's message of Thu, 31 Aug 89 18:15:50 edt <8908312215.AA07597@zurich.ai.mit.edu>
Subject: Programmer-defined data types, version 2
Date: Thu, 31 Aug 89 18:15:50 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Date: Thu, 31 Aug 89 13:26:10 -0700
From: Morris J. Katz <katz@Polya.Stanford.EDU>
Date: Thu, 31 Aug 89 14:42:33 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Date: Wed, 30 Aug 89 12:02:13 -0700
From: "Morris J. Katz" <katz@polya.stanford.edu>
For aesthetic reasons I would prefer to see
(MAKE-RECORD-TYPE type-name . field-names)
rather than
(MAKE-RECORD-TYPE type-name field-names)
as the for for MAKE-RECORD-TYPE.
How do others feel?
I prefer having a single argument which is a list. Not only does this
reduce the number of characters that must be typed, but it simplifies
abstraction on the `field-names' argument, and leaves the argument
list open for adding arguments in the future.
I might be swayed that it is important to leave the rest argument
position open for future extensions; but, I hardly buy that the
trade-off between 3 characters to form the list and one character per
symbol to make it into a symbol represents enough of a difference in
keystrokes to be important. (My approach is actually shorter for
records of 1 or 2 fields (-:)
Since I was obviously making an aesthetic argument, let's just
summarize by saying I prefer the aesthetics of a single list argument.
(I notice that you said nothing about my "abstraction" argument.)
Maybe I am just being dense, but I am not sure to what you are
refering in your abstraction argument. It is for that reason that I
did not respond to it.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂01-Sep-89 0909 katz@polya.stanford.edu Multiple values not for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 09:09:16 PDT
Received: from Polya.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA04753; Fri, 1 Sep 89 11:57:37 EDT
Received: by Polya.Stanford.EDU (5.61/25-eef) id AA05427; Fri, 1 Sep 89 08:56:44 -0700
Date: Fri, 1 Sep 89 08:56:44 -0700
From: Morris J. Katz <katz@polya.stanford.edu>
Message-Id: <8909011556.AA05427@Polya.Stanford.EDU>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: ramsdell@linus.mitre.org's message of Fri, 01 Sep 89 08:48:37 EDT <8909011248.AA05551@huxley.mitre.org>
Subject: Multiple values not for R4RS
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Posted-Date: Fri, 01 Sep 89 08:48:37 EDT
From: ramsdell@linus.mitre.org
Date: Fri, 01 Sep 89 08:48:37 EDT
>> From: Morris J. Katz <katz@Polya.Stanford.EDU>
...
>> During the evaluation of a 'with-values' form, the 'generator' thunk
>> is first thawed (evaluated to yield some values) and then the 'receiver' is
>> applied to the values returned by 'generator'. This means that a
>> continuation captured in 'generator' includes the application of
>> 'receiver' to the values returned by 'generator'. It also includes the
>> return from 'with-values' of the value(s) returned by 'receiver'.
The problem I see with this text is that the continuation captured in
'generator' may not be the one your text suggests. Consider
(baby-doe
(lambda ()
(let ((x (call-with-current-continuation
(lambda (c) ...))))
....))
...)
We can leave it to the editors (since that seems to be the current
sentiment), but I believe that my wording is actually correct relative
to your example. The continuation which is captured does include the
application of 'receiver' to the values returned by 'generator', just
possibly not as the first action to be taken by the continuation. I
tried to be fairly careful in my wording precisely because of the
example you have given.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂01-Sep-89 0914 katz@polya.stanford.edu An alternative to ACCEPTS?
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 09:14:00 PDT
Received: from Polya.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA04805; Fri, 1 Sep 89 12:02:25 EDT
Received: by Polya.Stanford.EDU (5.61/25-eef) id AA05706; Fri, 1 Sep 89 09:01:37 -0700
Date: Fri, 1 Sep 89 09:01:37 -0700
From: Morris J. Katz <katz@polya.stanford.edu>
Message-Id: <8909011601.AA05706@Polya.Stanford.EDU>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: ramsdell@linus.mitre.org's message of Fri, 01 Sep 89 10:41:58 EDT <8909011441.AA05581@huxley.mitre.org>
Subject: An alternative to ACCEPTS?
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Posted-Date: Fri, 01 Sep 89 10:41:58 EDT
From: ramsdell@linus.mitre.org
Date: Fri, 01 Sep 89 10:41:58 EDT
[This is not part of the multiple values compromise.]
As an alternative to providing ACCEPTS?, maybe we should simply
provide a way of generating truncating continuations. Suppose we
provided a procedure like CALL-WITH-CURRENT-CONTINUATION, except that
if the escape procedure generated by CALL-WITH-CURRENT-CONTINUATION
accepts exactly n arguments, the new procedure generates an escape
procedure which will accept n or more arguments, and ignore the extra
ones. The advantage of this approach is that implementations are only
required to be able to compute the arity of escape procedures, not all
procedures. Here is an example of its use:
(define (quotient-and-maybe-remainder n1 n2)
(call-with-truncating-continuation
(lambda (k)
(let* ((q (quotient n1 n2))
(r (- n1 (* q n2))))
(k q r)))))
(quotient-and-maybe-remainder 1 1) => 1
John
I would be unhappy with a special mechanism that handles only half of
the interesting cases. It virtually guarantees that no mechanism
which handles the entire problem will be adopted in the foreseeable
future. This is particularly true in this case in which their is no
natural extension of the special purpose mechanism to a more general one.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂01-Sep-89 0949 ramsdell@linus.mitre.org Re: Multiple values not for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 09:49:21 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA05179; Fri, 1 Sep 89 12:39:59 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA24183; Fri, 1 Sep 89 12:40:28 EDT
Posted-Date: Fri, 01 Sep 89 12:33:42 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA05694; Fri, 1 Sep 89 12:33:44 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8909011633.AA05694@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: Re: Multiple values not for R4RS
In-Reply-To: Your message of Fri, 01 Sep 89 08:56:44 -0700.
<8909011556.AA05427@Polya.Stanford.EDU>
Date: Fri, 01 Sep 89 12:33:42 EDT
>> From: Morris J. Katz <katz@Polya.Stanford.EDU>
...
>> We can leave it to the editors (since that seems to be the current
>> sentiment) ....
Leave it to the editors if you want to, not because it seems to be the
current sentiment. You count!
I understand your text now. I guess I find the term "includes"
ambiguous. Let me suggest another approach to explaining BABY-DOE.
I follow the lead of Will and the semantics.
The BABY-DOE procedure takes a thunk and a procedure, and calls the
thunk with a continuation that, when passed some values, calls the
procedure that was the second argument to the BABY-DOE procedure with
those values as arguments. The result of a call of the BABY-DOE
procedure is the result of the call of the second argument.
John
∂01-Sep-89 1050 Pavel.pa@xerox.com Re: An alternate description of the multiple values proposal
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 10:50:19 PDT
Received: from Xerox.COM by life.ai.mit.edu (4.1/AI-4.10) id AA05737; Fri, 1 Sep 89 13:40:41 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 SEP 89 10:40:23 PDT
Date: Fri, 01 Sep 89 10:40:57 PDT
From: Pavel.pa@xerox.com
Subject: Re: An alternate description of the multiple values proposal
In-Reply-To: <8909011308.AA05558@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Message-Id: <890901-104023-1225@Xerox>
I have a disagreement with Will's description of the consensus. He says,
``Except for continuations created by the procedure to be named later, all
continuations take exactly one value, as now''. I firmly believe that
continuations for the ``for effect'' context should take any number of
arguments; I would very much not like to see this left unspecified.
I agree with Jinx's correction to my description of CALL-WITH-VALUES
(stating that the producer accepts zero arguments instead of insisting that
it be a procedure of exactly zero arguments).
John, I appreciate that you were responding to my concerns when you removed
the special-casing from the description of VALUES, but that was not the
greatest of my concerns. My major issues concern some added degree of
precision in the description and also a statement about the arity of ``for
effect'' continuations. That's why I felt the need to propose a different
description. Let me respond to your comments on that decription.
You say, ``I think that the BABY-DOE procedure should include text that
makes it clear what happens when the continuation given to the producer is
captured by CALL-WITH-CURRENT-CONTINUATION.''
I thought the combination of the statements ``Consumer is applied to the
value(s) returned by invoking producer. CALL-WITH-VALUES returns the
result(s) of the invocation of consumer.'' and the discussion of the sixth
context in the description of CALL-WITH-CURRENT-CONTINUATION made it clear
what happens. If not, could you suggest a sentence or two that improves
the situation?
On the subject of naming BABY-DOE, consider the only procedures in R3.95RS
whose names begin with ``WITH-'':
WITH-INPUT-FROM-FILE
WITH-OUTPUT-TO-FILE
Both of these have an effect with dynamic extent, and the ``body''
procedure in each case is a thunk. Thus, the effect of these procedures is
to do some magic that lets the bodies behave differently than they would
without the procedure.
On the other hand, the procedures with ``CALL-WITH-'' in their names are as
follows:
CALL-WITH-CURRENT-CONTINUATION
CALL-WITH-INPUT-FILE
CALL-WITH-OUTPUT-FILE
These all take a ``body'' procedure and zero or one other arguments. A
computation is done on the other arguments and the result is passed as an
argument to the body procedure. No dynamic extent magic is involved and
the context of the body is no different than what it would be if it were
not an argument to one of these procedures.
I think that the resemblence of BABY-DOE to the latter set of procedures is
quite strong and that the resemblence to the former set is quite weak if it
exists at all. Thus, on the grounds of consistency in naming, I support
CALL-WITH-VALUES.
Pavel
∂01-Sep-89 1404 cph@zurich.ai.mit.edu An alternate description of the multiple values proposal
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 14:04:33 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA07990; Fri, 1 Sep 89 16:35:01 EDT
Received: from localhost by zurich.ai.mit.edu; Fri, 1 Sep 89 16:31:46 edt
Date: Fri, 1 Sep 89 16:31:46 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8909012031.AA10876@zurich.ai.mit.edu>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: ramsdell@linus.mitre.org's message of Fri, 01 Sep 89 09:08:45 EDT <8909011308.AA05558@huxley.mitre.org>
Subject: An alternate description of the multiple values proposal
From: ramsdell@linus.mitre.org
Date: Fri, 01 Sep 89 09:08:45 EDT
On naming BABY-DOE, I think we can assume that Pavel suggests
CALL-WITH-VALUES and Chris Hanson suggests WITH-VALUES.
I've changed my mind. I now agree with Pavel and prefer
`call-with-values'.
∂01-Sep-89 1419 cph@zurich.ai.mit.edu An alternate description of the multiple values proposal
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 14:19:10 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA08316; Fri, 1 Sep 89 16:58:11 EDT
Received: from localhost by zurich.ai.mit.edu; Fri, 1 Sep 89 16:55:00 edt
Date: Fri, 1 Sep 89 16:55:00 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8909012055.AA10886@zurich.ai.mit.edu>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Fri, 01 Sep 89 10:40:57 PDT <890901-104023-1225@Xerox>
Subject: An alternate description of the multiple values proposal
Date: Fri, 01 Sep 89 10:40:57 PDT
From: Pavel.pa@xerox.com
I have a disagreement with Will's description of the consensus. He says,
``Except for continuations created by the procedure to be named later, all
continuations take exactly one value, as now''. I firmly believe that
continuations for the ``for effect'' context should take any number of
arguments; I would very much not like to see this left unspecified.
I'm not sure I agree with this definition of "for effect"
continuations. I do agree that they should be required to accept
either zero arguments (because that is the "correct" arity for a
strict semantics) or one argument (for compatibility with existing
code). However, I see no compelling reason why such continuations
should be required to accept more than one argument. I would prefer
to leave this unspecified, because I believe it is an exact parallel
with the case of "for value" implicit continuations accepting more
than one argument.
(I can imagine that if I were considering the design of a new
language, I might choose a strict semantics in which "for effect"
implicit continuations accepted -only- zero arguments, and "for value"
implicit continuations accepted -only- one argument. There is a
simple elegance in such a design that I find appealing.)
∂01-Sep-89 1505 Pavel.pa@xerox.com Re: An alternate description of the multiple values proposal
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 15:05:05 PDT
Received: from Xerox.COM by life.ai.mit.edu (4.1/AI-4.10) id AA09028; Fri, 1 Sep 89 17:53:34 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 SEP 89 14:49:31 PDT
Date: Fri, 01 Sep 89 14:50:23 PDT
From: Pavel.pa@xerox.com
Subject: Re: An alternate description of the multiple values proposal
In-Reply-To: <8909012055.AA10886@zurich.ai.mit.edu>
To: rrrs-authors@life.ai.mit.edu
Message-Id: <890901-144931-1853@Xerox>
Date: Fri, 1 Sep 89 16:55:00 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
I'm not sure I agree with this definition of "for effect"
continuations. I do agree that they should be required to accept
either zero arguments (because that is the "correct" arity for a
strict semantics) or one argument (for compatibility with existing
code). However, I see no compelling reason why such continuations
should be required to accept more than one argument. I would prefer
to leave this unspecified, because I believe it is an exact parallel
with the case of "for value" implicit continuations accepting more
than one argument.
After sending my note, I took a look at the current (R3.95RS) semantics.
It shows a continuation for ``commands'' (that is, expressions in
``effect'' context) that takes any sequence of values and ignores all of
them. Of course, the formal semantics has no weight, but I found it
interesting.
I think that I have always been bothered by languages (like Pascal and
Mesa) that require me to ``do'' something with the returned values of
procedures. It always seems to me that I already explained what to do with
them: ignore them. Thus, I don't quite agree with the feeling that zero
values is somehow the ``correct'' number for expressions in effect context.
I can, however, appreciate something of the general gestalt that gives you
that feeling.
I think that my major reason for wanting effect continuations to accept
many values is for consistency with single-value-returning expressions; I
don't see a compelling reason to distinguish the two unnecessarily. It
would seem weird to me if single-valued expressions somehow got preference
over multiple-valued ones in such a case, in which there appears no
semantic justification.
Pavel
∂01-Sep-89 1507 jinx@zurich.ai.mit.edu An alternate description of the multiple values proposal
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 15:07:08 PDT
Received: from zurich.ai.mit.edu ([18.43.0.171]) by life.ai.mit.edu (4.1/AI-4.10) id AA09113; Fri, 1 Sep 89 18:01:10 EDT
Received: from localhost by zurich.ai.mit.edu; Fri, 1 Sep 89 17:57:54 edt
Date: Fri, 1 Sep 89 17:57:54 edt
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <8909012157.AA14800@zurich.ai.mit.edu>
To: cph@zurich.ai.mit.edu
Cc: Pavel.pa@xerox.com, rrrs-authors@life.ai.mit.edu
In-Reply-To: Chris Hanson's message of Fri, 1 Sep 89 16:55:00 edt <8909012055.AA10886@zurich.ai.mit.edu>
Subject: An alternate description of the multiple values proposal
(I can imagine that if I were considering the design of a new
language, I might choose a strict semantics in which "for effect"
implicit continuations accepted -only- zero arguments, and "for value"
implicit continuations accepted -only- one argument. There is a
simple elegance in such a design that I find appealing.)
There are a few problems with requiring "effect" continuations to expect
exactly zero values:
- Backwards compatibility (obviously not a problem with a new
language).
- Is the continuation for the call to FOO an effect continuation or
not?
(let ((ignored (foo <some args>)))
<some code that does not use ignored>)
- If it is not, then BEGIN is more primitive than I would like to see
it, since the "traditional" expansion as
(begin <exp1> <more>) ->
(let ((ignored1 <exp1>)
(next1 (lambda () (begin <more>))))
(next1))
no longer works because the arity of the continuation will be wrong.
- If it is an effect continuation, we have a problem, since in general
we can't decide statically whether a return value will be used or
not, and thus we can't decide in general whether a continuation is
for effect or not.
∂01-Sep-89 1516 cph@zurich.ai.mit.edu An alternate description of the multiple values proposal
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 15:16:11 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA09234; Fri, 1 Sep 89 18:07:18 EDT
Received: from localhost by zurich.ai.mit.edu; Fri, 1 Sep 89 18:04:02 edt
Date: Fri, 1 Sep 89 18:04:02 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8909012204.AA14425@zurich.ai.mit.edu>
To: jinx@zurich.ai.mit.edu
Cc: Pavel.pa@xerox.com, rrrs-authors@life.ai.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Fri, 1 Sep 89 17:57:54 edt
Subject: An alternate description of the multiple values proposal
Date: Fri, 1 Sep 89 17:57:54 edt
From: jinx (Guillermo J. Rozas)
(I can imagine that if I were considering the design of a new
language, I might choose a strict semantics in which "for effect"
implicit continuations accepted -only- zero arguments, and "for value"
implicit continuations accepted -only- one argument. There is a
simple elegance in such a design that I find appealing.)
There are a few problems with requiring "effect" continuations to expect
exactly zero values:
- Is the continuation for the call to FOO an effect continuation or
not?
(let ((ignored (foo <some args>)))
<some code that does not use ignored>)
- If it is not, then BEGIN is more primitive than I would like to see
it, since the "traditional" expansion as
(begin <exp1> <more>) ->
(let ((ignored1 <exp1>)
(next1 (lambda () (begin <more>))))
(next1))
no longer works because the arity of the continuation will be wrong.
The continuation for this call is -not- an "effect" continuation. I
don't see this as a problem -- it merely means that the expansion for
`begin' must be described in terms of `call-with-values':
(begin <action> <more>) ->
(call-with-values (lambda () <action>) (lambda () (begin <more>)))
I don't see this as being appreciably different. I also don't see any
problem with "primitiveness" since `call-with-values' must be
implemented as a primitive in any case.
∂01-Sep-89 1635 Pavel.pa@xerox.com Re: An alternate description of the multiple values proposal
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 16:35:35 PDT
Received: from Xerox.COM by life.ai.mit.edu (4.1/AI-4.10) id AA09710; Fri, 1 Sep 89 18:47:06 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 SEP 89 15:41:54 PDT
Date: Fri, 01 Sep 89 15:42:50 PDT
From: Pavel.pa@xerox.com
Subject: Re: An alternate description of the multiple values proposal
In-Reply-To: <8909012204.AA14425@zurich.ai.mit.edu>
To: rrrs-authors@life.ai.mit.edu
Message-Id: <890901-154154-1998@Xerox>
I also don't see the call in Jinx's example as being in effect context. I
think Chris is right about defining BEGIN in terms of CALL-WITH-VALUES. Of
course, Chris and I disagree about the argument list of the consumer:
(begin <action> <more>) ->
(call-with-values (lambda () <action>)
(lambda ignored (begin <more>)))
It is interesting to note that the formal semantics gives a very different
translation of BEGIN:
(begin <sequence>) -> ((lambda () <sequence>))
∂01-Sep-89 1653 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu Programmer-defined data types, version 2
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 16:53:10 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA09912; Fri, 1 Sep 89 18:59:26 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20407;
1 Sep 89 16:46 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Sep 89 16:46:19 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20337;
1 Sep 89 16:41 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA08073; Fri, 1 Sep 89 16:41:49 EDT
Received: from localhost by zurich.ai.mit.edu; Fri, 1 Sep 89 16:38:38 edt
Date: Fri, 1 Sep 89 16:38:38 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8909012038.AA10881@zurich.ai.mit.edu>
To: katz@polya.stanford.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Morris J. Katz's message of Fri, 1 Sep 89 08:42:07 -0700 <8909011542.AA04825@Polya.Stanford.EDU>
Subject: Programmer-defined data types, version 2
Date: Fri, 1 Sep 89 08:42:07 -0700
From: Morris J. Katz <katz@Polya.Stanford.EDU>
Date: Thu, 31 Aug 89 18:15:50 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Date: Thu, 31 Aug 89 13:26:10 -0700
From: Morris J. Katz <katz@Polya.Stanford.EDU>
I might be swayed that it is important to leave the rest argument
position open for future extensions; but, I hardly buy that the
trade-off between 3 characters to form the list and one character per
symbol to make it into a symbol represents enough of a difference in
keystrokes to be important. (My approach is actually shorter for
records of 1 or 2 fields (-:)
Since I was obviously making an aesthetic argument, let's just
summarize by saying I prefer the aesthetics of a single list argument.
(I notice that you said nothing about my "abstraction" argument.)
Maybe I am just being dense, but I am not sure to what you are
refering in your abstraction argument. It is for that reason that I
did not respond to it.
What I mean by being able to "abstract" on that argument is that its
value can by computed as an arbitrary expression. I can easily
imagine circumstances where this is desirable.
On the other hand, I could do this with a rest argument by means of
`apply'; but I find that alternative clumsy and unattractive.
Furthermore, it feels like a kludge to compensate for the fact that
the "field list" no longer has any distinct identity.
∂01-Sep-89 1857 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Programmer-defined data types, last (?) version
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 18:57:05 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA09987; Fri, 1 Sep 89 19:09:40 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20657;
1 Sep 89 17:07 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Sep 89 17:07:39 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20599;
1 Sep 89 17:04 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08408; Fri, 1 Sep 89 17:04:33 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 1 Sep 89 17:01:04 edt
Received: from Cabernet.ms by ArpaGateway.ms ; 01 SEP 89 13:49:26 PDT
Date: Fri, 01 Sep 89 13:50:16 PDT
From: Pavel.pa@xerox.com
Subject: Programmer-defined data types, last (?) version
To: RRRS-Authors@zurich.ai.mit.edu
Cc: Pavel.pa@xerox.com
Message-Id: <890901-134926-1681@Xerox>
Morry Katz suggested that the field-names argument to MAKE-RECORD-TYPE be
spread out, as the 2nd through nth arguments. I agree with Chris Hanson in
his opposition to this, primarily because I want to be able to extend this
functionality with extra, optional arguments to MAKE-RECORD-TYPE (e.g., in
Cedar Scheme, an optional parent rtd and printing procedure can be given).
In private mail, Alan Bawden asked for a more explicit statement concerning
the order of arguments to record updaters (it is as in SET-CAR!, with the
record to be changed followed by the new value for the field). I have done
this below.
Alan also asked for more information about the result of applying RECORD?
to various types of values, such as pairs, promises, numbers, etc. I have
updated its description to say that RECORD? may return true for any Scheme
value; of course, if it does so, then RECORD-TYPE-DESCRIPTOR will also be
applicable to that value and will return an ``appropriate'' record-type
descriptor. I also added a note to the effect that the type of descriptors
is not necessarily disjoint from the other types in Scheme.
Jonathan Rees points out that, given the optionality of the second argument
to RECORD-CONSTRUCTOR, it is gratuitous to have RECORD-TYPE-FIELD-NAMES
return some random permutation of the original list. I agree and have
changed the description back to its previous form, specifying that the
resulting list is EQUAL? to the one given when the type was created.
Here is the third and, I dare to hope, final version of the proposal.
Will, does this look like consensus?
Pavel
=====================
We propose adding the following procedures to Scheme:
(MAKE-RECORD-TYPE type-name field-names)
Returns a ``record-type descriptor'', a value representing a new data type,
disjoint from all others. The type-name argument must be a string, but is
only used for debugging purposes (such as the printed representation of a
record of the new type). The field-names argument is a list of symbols
naming the ``fields'' of a record of the new type. It is an error if the
list contains any duplicates. It is unspecified how record-type
descriptors are represented.
(RECORD-CONSTRUCTOR rtd [field-names])
Returns a procedure for constructing new members of the type represented by
rtd. The returned procedure accepts exactly as many arguments as there are
symbols in the given list, field-names; these are used, in order, as the
initial values of those fields in a new record, which is returned by the
constructor procedure. The values of any fields not named in that list are
unspecified. The field-names argument defaults to the list of field-names
in the call to MAKE-RECORD-TYPE that created the type represented by rtd;
if the field-names argument is provided, it is an error if it contains any
duplicates or any symbols not in the default list.
(RECORD-PREDICATE rtd)
Returns a procedure for testing membership in the type represented by rtd.
The returned procedure accepts exactly one argument and returns a true
value if the argument is a member of the indicated record type; it returns
a false value otherwise.
(RECORD-ACCESSOR rtd field-name)
Returns a procedure for reading the value of a particular field of a member
of the type represented by rtd. The returned procedure accepts exactly one
argument which must be a record of the appropriate type; it returns the
current value of the field named by the symbol field-name in that record.
The symbol field-name must be a member of the list of field-names in the
call to MAKE-RECORD-TYPE that created the type represented by rtd.
(RECORD-UPDATER rtd field-name)
Returns a procedure for writing the value of a particular field of a member
of the type represented by rtd. The returned procedure accepts exactly two
arguments: first, a record of the appropriate type, and second, an
arbitrary Scheme value; it modifies the field named by the symbol
field-name in that record to contain the given value. The returned value
of the updater procedure is unspecified. The symbol field-name must be a
member of the list of field-names in the call to MAKE-RECORD-TYPE that
created the type represented by rtd.
(RECORD? obj)
Returns a true value if obj is a record of any type and a false value
otherwise. Note that RECORD? may be true of any Scheme value; of course,
if it returns true for some particular value, then RECORD-TYPE-DESCRIPTOR
is applicable to that value and returns an appropriate descriptor.
(RECORD-TYPE-DESCRIPTOR record)
Returns a record-type descriptor representing the type of the given record.
That is, for example, if the returned descriptor were passed to
RECORD-PREDICATE, the resulting predicate would return a true value when
passed the given record. Note that it is not necessarily the case that the
returned descriptor is the one that was passed to RECORD-CONSTRUCTOR in the
call that created the constructor procedure that created the given record.
(RECORD-TYPE-NAME rtd)
Returns the type-name associated with the type represented by rtd. The
returned value is EQV? to the type-name argument given in the call to
MAKE-RECORD-TYPE that created the type represented by rtd.
(RECORD-TYPE-FIELD-NAMES rtd)
Returns a list of the symbols naming the fields in members of the type
represented by rtd. The returned value is EQUAL? to the field-names
argument given in the call to MAKE-RECORD-TYPE that created the type
represented by rtd.
=====================
Notes on the proposal
=====================
-- The procedure RECORD? is necessary to allow reliable use of the
procedure RECORD-TYPE-DESCRIPTOR.
-- The type-name argument to MAKE-RECORD-TYPE is constrained to be a string
in order to allow experimentation with interesting semantics for other
kinds of values there. One possibility raised in the discussion in May and
June of 1988 was some kind of a ``handler'' procedure, as in T objects.
-- We do not propose any general macro for the definition of record types.
The feeling is that this is not easy to do in a way that is both elegant
and sufficiently flexible. Once we have macros, the primitives above
should be sufficient for portable experimentation.
-- The issues of subtyping and inheritance, print methods, and integration
with modules and/or
environments (e.g., Pascal's WITH construct) have been purposely avoided in
order to achieve more rapid consensus. Designs for adding single
inheritance appeared in the discussion in 1988.
-- EQ? and EQV? treat records in the same way as they do pairs, vectors,
and strings. EQUAL? is equivalent to EQV? on records.
∂05-Sep-89 0916 ramsdell@linus.mitre.org Name for BABY-DOE should not include "values".
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 5 Sep 89 09:16:05 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA04716; Tue, 5 Sep 89 11:54:56 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA19127; Tue, 5 Sep 89 08:59:53 EDT
Posted-Date: Tue, 05 Sep 89 08:53:08 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA09039; Tue, 5 Sep 89 08:53:09 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8909051253.AA09039@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Name for BABY-DOE should not include "values".
In-Reply-To: Your message of Fri, 01 Sep 89 16:31:46 -0400.
<8909012031.AA10876@zurich.ai.mit.edu>
Date: Tue, 05 Sep 89 08:53:08 EDT
I prefer a name for BABY-DOE which does not include the word "values".
The reason is that I believe such names are misleading. In my
opinion, BABY-DOE gives me a way of creating an unusual continuation
to be used during a call of a thunk. It is unusual because it splices
in a call of a procedure into the current continuation. The important
fact about BABY-DOE is not that it calls a procedure with some values.
Please verify my point by studying the formal semantics.
Unfortunately, I have not yet come up with a good alternative name.
Here are some of my current tries:
CALL-PREFIXING-CONTINUATION
CALL-SPLICING-CONTINUATION
CALL-FORWARDING
CONNECT
LINK
CPS-CALL for "Continuation Passing Style CALL"
John
∂05-Sep-89 0918 ramsdell@linus.mitre.org Re: An alternate description of the multiple values proposal
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 5 Sep 89 09:18:33 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA04875; Tue, 5 Sep 89 12:06:57 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA19941; Tue, 5 Sep 89 09:45:21 EDT
Posted-Date: Tue, 05 Sep 89 09:38:35 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA09068; Tue, 5 Sep 89 09:38:36 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8909051338.AA09068@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Re: An alternate description of the multiple values proposal
In-Reply-To: Your message of Fri, 01 Sep 89 15:42:50 -0700.
<890901-154154-1998@Xerox>
Date: Tue, 05 Sep 89 09:38:35 EDT
So do people agree with Will's statement that we should not worry
about the wording of a multiple values proposal? I am quite willing
to trust the editors. I assume we will agree, so, I will refrain from
making editorial comments.
>> From: Pavel.pa@xerox.com
...
>> I have a disagreement with Will's description of the consensus. He says,
>> ``Except for continuations created by the procedure to be named later, all
>> continuations take exactly one value, as now''. I firmly believe that
>> continuations for the ``for effect'' context should take any number of
>> arguments; I would very much not like to see this left unspecified.
...
It seems to me that Will's description of the consensus is a good one
in the sense that it represents the minimum change required to get
usable multiple values into Scheme. It represents a compromise I
suspect all will embrace. I hope Pavel agrees it is better than
nothing.
I suggest that the arity of `for effect' continuations be left as the
subject of a separate agenda item. Simply put, I do not want to risk
the multiple values compromise on this point. Remember, the consensus
on multiple values is not supposed to be the last word on the subject.
I expect further proposals on procedures related to ACCEPT? for
example.
John
∂05-Sep-89 1446 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net:jmiller@cs.brandeis.edu Programmer-defined data types, last (?) version
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 5 Sep 89 14:45:54 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA08791; Tue, 5 Sep 89 17:31:31 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa10878;
5 Sep 89 17:26 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 5 Sep 89 17:26:48 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa10766;
5 Sep 89 17:20 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08614; Tue, 5 Sep 89 17:20:08 EDT
Received: from RELAY.CS.NET (relay.cs.net) by zurich.ai.mit.edu; Tue, 5 Sep 89 17:16:51 edt
Message-Id: <8909052116.AA28244@zurich.ai.mit.edu>
Received: from relay2.cs.net by RELAY.CS.NET id ab20537; 5 Sep 89 16:11 EDT
Received: from cs.brandeis.edu by RELAY.CS.NET id ad03696; 5 Sep 89 17:09 EDT
Received: by cs.brandeis.edu (14.2/6.0.GT)
id AA19086; Tue, 5 Sep 89 07:27:19 edt
Date: Tue, 5 Sep 89 07:27:19 edt
From: Jim Miller <jmiller%cs.brandeis.edu@relay.cs.net>
Posted-Date: Tue, 5 Sep 89 07:27:19 edt
To: Pavel.pa.2@cs.brandeis.edu
Cc: RRRS-Authors.2@cs.brandeis.edu, Pavel.pa.2@cs.brandeis.edu
In-Reply-To: Pavel.pa@xerox.com's message of Fri, 01 Sep 89 13:50:16 PDT <890901-134926-1681@Xerox>
Subject: Programmer-defined data types, last (?) version
Reply-To: JMiller%cs.Brandeis.edu@relay.cs.net
Sorry, but I was waiting for something close to consensus to emerge
before sending in my one picky comment about the proposal. I don't
like the fact that the type name is a string, and the rationale makes
no sense to me whatsoever. As I understand it, you want to force the
T experiments to be non-portable EVEN IF the user never uses the
properties of the object that are the type's name? Why not leave the
position entirely unrestricted, since it has only one property of
interest: given a record you can retrieve this value. Surely, even
the most exotic experiments are unlikely to depend on the fact that
this object can't be retrieved once it is used to create a record
constructor?
--Jim
∂05-Sep-89 2222 Pavel.pa@xerox.com Re: Name for BABY-DOE should not include "values".
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 5 Sep 89 22:22:30 PDT
Received: from Xerox.COM by life.ai.mit.edu (4.1/AI-4.10) id AA12651; Wed, 6 Sep 89 00:10:00 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 SEP 89 15:08:31 PDT
Date: Tue, 05 Sep 89 15:14:16 PDT
From: Pavel.pa@xerox.com
Subject: Re: Name for BABY-DOE should not include "values".
In-Reply-To: <8909051253.AA09039@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Message-Id: <890905-150831-2109@Xerox>
John says, ``The important fact about BABY-DOE is not that it calls a
procedure with some values. Please verify my point by studying the formal
semantics.''
I disagree completely; to my mind, that is the entire significance of
BABY-DOE. I don't see that there is anything ``unusual'' about the
continuation created by BABY-DOE. It is just one of several kinds of
continuations, each with very different behavior, created by IF, SET!,
function-application, etc. In short, I don't think it needs a name
referring to continuations any more than IF or SET! does. Of course, it is
an operation on continuations, but most things are.
None of John's current tries at a better name seems even close to having
the perspicacity of ``call-with-values''.
Pavel
∂05-Sep-89 2349 @mc.lcs.mit.edu,@life.ai.mit.edu:bawden@arisia.xerox.com Programmer-defined data types, last (?) version
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 5 Sep 89 23:49:04 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA13349; Wed, 6 Sep 89 02:26:57 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13781;
5 Sep 89 22:08 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 5 Sep 89 22:08:19 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa13769;
5 Sep 89 22:06 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA11092; Tue, 5 Sep 89 22:05:51 EDT
Received: from arisia.Xerox.COM (arisia.xerox.com) by zurich.ai.mit.edu; Tue, 5 Sep 89 22:02:36 edt
Received: from roo.parc.Xerox.COM by arisia.Xerox.COM with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA23168; Tue, 5 Sep 89 19:02:01 -0700
Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA03460; Tue, 5 Sep 89 19:05:03 PDT
Date: Tue, 5 Sep 89 19:03 PDT
From: Alan Bawden <bawden@parc.xerox.com>
Subject: Programmer-defined data types, last (?) version
To: JMiller%cs.Brandeis.edu@relay.cs.net
Cc: Pavel.pa@xerox.com, RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: <8909052116.AA28244@zurich.ai.mit.edu>
Message-Id: <19890906020319.1.ALAN@MR-BUN.parc.xerox.com>
Date: Tue, 5 Sep 89 07:27:19 edt
From: Jim Miller <jmiller%cs.brandeis.edu@relay.cs.net>
... I don't like the fact that the type name is a string, and the
rationale makes no sense to me whatsoever.... Why not leave the
position entirely unrestricted, since it has only one property of
interest: given a record you can retrieve this value.
Perhaps I want to write a portable browser. I want to be able to display
things like:
The object #<RECORD 343241> is a Spaceship. It's fields are:
CAPTAIN: #<RECORD 442425>
X-POS: 3142.776
Y-POS: 0.0
If an implementation is free to re-use that argument, assigning it a role
other than as a DISPLAYable representation of the type, then in that
implementation you will see:
The object #<RECORD 343241> is a #<CLASS 671726>.
It's fields are:
CAPTAIN: #<RECORD 442425>
X-POS: 3142.776
Y-POS: 0.0
So my browser wasn't really portable after all.
It is true that the only formal property you can specify about the first
argument to MAKE-RECORD-TYPE is that you can read it back later. But
programming languages are more than just a denotational semantics.
MAKE-RECORD-TYPE has an infinite number of arguments left unspecified
(assuming we don't adopt a recent proposal), which seems to me plenty of
room to experiment. Why insist on overloading the first one?
∂06-Sep-89 0006 KMP@stony-brook.scrc.symbolics.com Baby-Doe and friends
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Sep 89 00:05:44 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM by life.ai.mit.edu (4.1/AI-4.10) id AA13346; Wed, 6 Sep 89 02:26:17 EDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 652712; 6 Sep 89 02:27:04 EDT
Date: Wed, 6 Sep 89 02:26 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: Baby-Doe and friends
To: Pavel.pa@xerox.com
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: <890905-150831-2109@Xerox>
Message-Id: <19890906062646.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
A few buffered up comments relating to this conversation...
- I strongly prefer CALL-WITH-VALUES to WITH-VALUES because my
background in other languages says that WITH-xxx forms should
be macros or special forms which have special syntaxes, usually
including an implicit-block body.
Given WITH-INPUT-FROM-FILE and WITH-OUTPUT-TO-FILE, I can't
make an argument of internal naming inconsistency for Scheme,
but I can say that I would change the names of those two functions
at the drop of a hat because I think they're badly misnamed.
- I think I mentioned before, but I'll say it again because it's
not getting much notice:
(CALL-xxx continuation function)
would make infinitely more sense to me than
(CALL-xxx function continuation)
since it is the continuation which is being called with values.
The fact that the function is a function is only an incidental
artifact. [i.e., if we had a separate datatype THUNK such that
(THUNK exp) meant like (LAMBDA () exp) except that THUNKs were
not `called', they were `frobbed', I think it would still make
sense to say
(CALL-xxx continuation thunk)
but it would be totally icky to say
(CALL-xxx thunk continuation)
In this thought exercise, you'd want to say
(FROB-xxx thunk continuation)
I believe.]
On the issue of internal consistency, CALL-WITH-CURRENT-CONTINUATION
takes only one arg, so I I can't construct an argument about whether
that argument is the first or the last, but the parallel with FUNCALL
in Lisp of anything named CALL-xxx is too strong and I just think it
will cause immeasurable headache for any CALL-xxx to not be like FUNCALL.
- I have a problem with the morpheme "values" in the multiple values
terminology. It's the reason I suggested YIELD earlier.
Part of the issue is that every object passed along a data-flow
path is, in effect, a value, so it seems contrived and potentially
confusion-inducing to designate some of those as VALUES and leave
the rest to merely be values.
The way a language is spoken aloud among people who program in it
is important to me. The following interchange in Common Lisp would
seem `natural' ...
``What does the function FOO return?''
``It returns (VALUES).''
(pronounced the same as ``It returns values.'')
One learns that the word "values" in spoken speech is shorthand for
``no values.'' It's really yucky. The reason I prefer (YIELD . values)
is that it doesn't admit this bizaree verbal shorthand and properly
encourages one to say either
``It returns no values''
or ``It yields no values.''
- As for naming BABY-DOE, I still like COMPOSE-CONTINUATION.
(COMPOSE-CONTINUATION CONS (LAMBDA () (YIELD 1 2))) => (1 . 2)
If you really want a CALL-xxx thing, maybe I could get into
CALL-WITH-INTERVENING-CONTINUATION cont fn
Other possible adjectives include composed, interposed,
encapsulated, augmented, composed, protected, ...
- If a truncating version of BABY-DOE is created, I think some thought
should be given to whether it should also pad with extra NIL's or some
such. A key reason for using such a thing in the first place would
presumably be to interface to Common Lisp, which has the other kind
of multiple values, and provides both padding and truncation.
However, since this kind of truncation can be added as a layered thing,
I see no reason to include it in R4RS Scheme.
∂06-Sep-89 0626 ramsdell@linus.mitre.org Re: Baby-Doe and friends
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Sep 89 06:26:42 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02617; Wed, 6 Sep 89 09:08:05 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA16223; Wed, 6 Sep 89 09:08:52 EDT
Posted-Date: Wed, 06 Sep 89 09:02:06 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA10116; Wed, 6 Sep 89 09:02:07 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8909061302.AA10116@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Re: Baby-Doe and friends
In-Reply-To: Your message of Wed, 06 Sep 89 02:26:00 -0400.
<19890906062646.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Wed, 06 Sep 89 09:02:06 EDT
It sounds to me that we all agree WITH-VALUES is no longer a viable
name for BABY-DOE.
>> From: Pavel.pa@xerox.com
...
>> John says, ``The important fact about BABY-DOE is not that it calls a
>> procedure with some values. Please verify my point by studying the formal
>> semantics.''
>>
>> I disagree completely; to my mind, that is the entire significance of
>> BABY-DOE. I don't see that there is anything ``unusual'' about the
>> continuation created by BABY-DOE. .....
At the begining of the search for a compromise on multiple values, we
all forgot that continuations should integrate with multiple values in
the natural way given by viewing BABY-DOE as a way of calling a thunk
with no arguments and a doctored continuation. This doctored
continuation is the result of prefixing the current continuation with
BABY-DOE's second argument. It is easy for the average user to assume
that Scheme's BABY-DOE is much like Common Lisp's MULTIPLE-VALUE-CALL,
but it is not. Let's find a name that will encourage users to make
the distinction.
I think the name CALL-WITH-CONTINUATION is too easily confused with
CALL-WITH-CURRENT-CONTINUATION. I like the name COMPOSE-CONTINUATION.
>> From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
...
>> - I have a problem with the morpheme "values" in the multiple values
>> terminology. It's the reason I suggested YIELD earlier.
I prefer YIELD to VALUES as well. When I tried to create a
description of VALUES, I found it strange writing about VALUES and its
value. Should we make this change, I hope there will not be a request
for CALL-WITH-YIELD as a name for BABY-DOE.
John
∂06-Sep-89 0821 gls@think.com Baby-Doe and friends
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Sep 89 08:21:42 PDT
Received: from Think.COM (Gateway.Think.COM) by life.ai.mit.edu (4.1/AI-4.10) id AA03495; Wed, 6 Sep 89 11:11:45 EDT
Received: from fafnir.think.com by Think.COM; Wed, 6 Sep 89 11:12:25 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 6 Sep 89 11:09:49 EDT
Received: by verdi.think.com; Wed, 6 Sep 89 11:09:27 EDT
Date: Wed, 6 Sep 89 11:09:27 EDT
From: gls@think.com (Guy Steele)
Message-Id: <8909061509.AA22038@verdi.think.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: Pavel.pa@xerox.com, rrrs-authors@life.ai.mit.edu
In-Reply-To: Kent M Pitman's message of Wed, 6 Sep 89 02:26 EDT <19890906062646.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Baby-Doe and friends
I applaud Kent's cogent attempt to find a rational terminology.
His point about the confusing uses of "VALUES" is well-taken.
Here is another approach to the question. Consider an intuitive
model in which arguments are "passed down" and values are
"returned up". (Yes, I know this runs afoul of the One True Way
of tail-recursion, but it suits my purposes here.)
Then we can describe the two proposed procedures in a reasonably symmetric
fashion: VALUES takes a set of objects headed downward as arguments and
bounces them back upward as values. (Think of a mirror. I would have said
"reflects" instead of "bounces" except the former already has another
technical meaning.) BABY-DOE takes a set of objects headed upward as
values and bounces them back downward as arguments.
I believe this symmetry to be quite real; the procedures seem asymmetric
only as a consequence of the asymmetry of function call notation, rather
than as a consequence of their intrinsic behaviors.
Therefore, if we retain the name VALUES for the one, one might reach the
logical, if not entirely aesthetic, conclusion that BABY-DOE should be
called ARGUMENTS.
--Guy
∂06-Sep-89 0859 katz@neon.stanford.edu Baby-Doe and friends
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Sep 89 08:58:53 PDT
Received: from Neon.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA03861; Wed, 6 Sep 89 11:48:49 EDT
Received: by Neon.Stanford.EDU (5.61/25-eef) id AA01411; Wed, 6 Sep 89 08:48:59 -0700
Date: Wed, 6 Sep 89 08:48:59 -0700
From: Morris J. Katz <katz@neon.stanford.edu>
Message-Id: <8909061548.AA01411@Neon.Stanford.EDU>
To: rrrs-authors@life.ai.mit.edu
Subject: Baby-Doe and friends
While I am not particularly enthralled with the names WITH-VALUES
(CALL-WITH-VALUES) or VALUES, I find all of the suggested alternatives
to be far more distasteful than the original names. From my
perspective, the two function names should be both reasonably short
and pneumonically meaningful. Another name like
call-with-current-continuation is unacceptable because it is
unreasonably verbose.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂06-Sep-89 1018 @mc.lcs.mit.edu:hieb@iuvax.cs.indiana.edu mutiple values, procedures and continuations
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Sep 89 10:18:18 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04557; Wed, 6 Sep 89 13:10:04 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22473;
6 Sep 89 13:09 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Sep 89 13:09:35 EDT
Received: from IUVAX.CS.INDIANA.EDU by mintaka.lcs.mit.edu id aa22454;
6 Sep 89 13:05 EDT
Received: by iuvax.cs.indiana.edu
Date: Wed, 6 Sep 89 12:04:41 -0500
From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: mutiple values, procedures and continuations
Message-Id: <8909061305.aa22454@mintaka.lcs.mit.edu>
I think the mv discussion could be helped considerably by keeping
procedures and continuations distinct.
Scheme procedures are not continuations.
It is an artifact of continuation semantics (and cps implementations)
that a procedure call can be thought of as composing a continuation
and a procedure. Continuation semantics (and cps implemetations)
convert lambda-expressions to semantic functions which take
continuations as arguments. Other semantics (and implementations)
may not.
The second argument to "with-values" is no more a continuation than the
first argument. "with-values" need do no more continuation-mucking than
"apply".
Names need only hint at functionality. We can leave some description for
the report instead of trying to do it all in the name. "apply" is a good
example of a short name (it could have been "call-procedure-with-supplied-
values-and-values-from-list-and-send-result\(s\)-to-current-continuation").
"call-with-current-continuation" is a bad example of a short name
(which is why I say "call/cc" and you say "cwcc"). I am satisfied with
"with-values" unless someone can find something shorter and sweeter.
Following Guy's line of thought I was briefly tempted with "seulav"...
∂06-Sep-89 1428 @mc.lcs.mit.edu,@life.ai.mit.edu:bawden@arisia.xerox.com Baby-Doe and friends
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Sep 89 14:28:36 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA06648; Wed, 6 Sep 89 17:04:55 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25000;
6 Sep 89 16:46 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Sep 89 16:46:53 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24839;
6 Sep 89 16:33 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06359; Wed, 6 Sep 89 16:33:30 EDT
Received: from arisia.Xerox.COM (arisia.xerox.com) by zurich.ai.mit.edu; Wed, 6 Sep 89 16:30:19 edt
Received: from roo.parc.Xerox.COM by arisia.Xerox.COM with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA14707; Wed, 6 Sep 89 13:29:20 -0700
Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA07366; Wed, 6 Sep 89 13:32:29 PDT
Date: Wed, 6 Sep 89 13:30 PDT
From: Alan Bawden <bawden@parc.xerox.com>
Subject: Baby-Doe and friends
To: rrrs-authors@zurich.ai.mit.edu
Cc: KMP@stony-brook.scrc.symbolics.com, Pavel.pa@xerox.com
In-Reply-To: <19890906062646.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-Id: <19890906203028.6.ALAN@MR-BUN.parc.xerox.com>
No one has yet suggested the name "RETURN" for the multiple-value creator.
Of course in Common Lisp the name is used for non-local exits, but it -is-
the verb that programmers commonly use to describe the act: "INTERN returns
two values".
(In fact, in older versions of ZetaLisp RETURN did -both- non-local exits
and multiple values, but in a fit of orthogonality (sounds painful!) that
feature was removed and made entirely the job of VALUES.)
To my ear, RETURN beats YIELD. To me YIELD is a word you see on traffic
signs where it makes a statement about rights.
As for BABY-DOE, I'm uncomfortable with any name that includes the word
"CONTINUATION" or that talks about "composition" of anything. Keep in mind
that unlike CALL-WITH-CURRENT-CONTINUATION, this is not a feature that only
Scheme wizards will use in bizare applications. We are adding multiple
values because we believe that ordinary programmers can benefit from using
this feature in mundane code, so the name needs to be convenient (unlike
CALL-WITH-CURRENT-CONTINUATION) and relevant to what programmers are using
BABY-DOE for. Programmers will be using BABY-DOE to recieve multiple
values; they will -not- be thinking in terms of continuations or about
composition of anything. Names like RECEIVE, RECEIVE-VALUES, WITH-VALUES
or even CALL-WITH-VALUES all seem to fit the bill.
It might be reasonable to adopt an inconvenient name, if a convenient
special form was also being proposed at the same time.
∂06-Sep-89 1619 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@zurich.ai.mit.edu Baby-Doe and friends
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Sep 89 16:19:01 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA08115; Wed, 6 Sep 89 19:03:17 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26236;
6 Sep 89 17:42 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Sep 89 17:43:18 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa26219;
6 Sep 89 17:40 EDT
Received: from zurich.ai.mit.edu ([18.43.0.171]) by life.ai.mit.edu (4.1/AI-4.10) id AA07080; Wed, 6 Sep 89 17:40:15 EDT
Received: from localhost by zurich.ai.mit.edu; Wed, 6 Sep 89 17:37:05 edt
Date: Wed, 6 Sep 89 17:37:05 edt
From: "Guillermo J. Rozas" <jinx@zurich.ai.mit.edu>
Message-Id: <8909062137.AA10332@zurich.ai.mit.edu>
To: bawden@parc.xerox.com
Cc: rrrs-authors@zurich.ai.mit.edu, KMP@stony-brook.scrc.symbolics.com,
Pavel.pa@xerox.com
In-Reply-To: Alan Bawden's message of Wed, 6 Sep 89 13:30 PDT <19890906203028.6.ALAN@MR-BUN.parc.xerox.com>
Subject: Baby-Doe and friends
To my ear, RETURN beats YIELD. To me YIELD is a word you see on traffic
signs where it makes a statement about rights.
RETURN has too much of a connotation of "immediate exit no matter
where you are".
∂07-Sep-89 0942 @mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:ziggy@hx.lcs.mit.edu RE: name for VALUES
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Sep 89 09:42:34 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA05047; Thu, 7 Sep 89 12:34:25 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09237;
7 Sep 89 12:27 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 7 Sep 89 12:15:35 EDT
Received: from HX.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 287628; 7 Sep 89 12:15:04 EDT
Received: by hx.LCS.MIT.EDU (5.51/4.7); Thu, 7 Sep 89 12:13:15 EDT
Date: Thu, 7 Sep 89 12:13:15 EDT
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
Message-Id: <8909071613.AA19084@hx.LCS.MIT.EDU>
To: rrrs-authors@zermatt.lcs.mit.edu
Subject: RE: name for VALUES
I too am not fond of YIELD since it is used in CLU for a different
purpose: there it is used to return multiple values but a dynamically
computed number of them, and it returns them one at a time to a FOR
statement which iterates over these YIELDed values. The construct which
does such YIELDing of values is aptly named an ITERATER.
I do not think that RETURN implies EXIT since the manual is careful
to call nonlocal exits just that rather than calling them something
like "immediate returns". In my low-level mind it just implies that
the values are placed in the RETURN register(s) and the current pending
continuation is invoked.
I also think it would be odd to have a section on multiple value
RETURN in which the construct which does the returning is called
YIELD.
Perhaps something like MVRETURN (for Multiple-Value-RETURN) or
RETURN/MV or RWMV?
~Ziggy
∂07-Sep-89 1013 @mc.lcs.mit.edu,@life.ai.mit.edu:jar@zurich.ai.mit.edu Baby-Doe and friends
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Sep 89 10:13:13 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA05621; Thu, 7 Sep 89 13:07:05 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09652;
7 Sep 89 13:00 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 7 Sep 89 13:00:38 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09623;
7 Sep 89 12:56 EDT
Received: from zurich.ai.mit.edu ([18.43.0.158]) by life.ai.mit.edu (4.1/AI-4.10) id AA05454; Thu, 7 Sep 89 12:56:58 EDT
Received: from localhost by zurich.ai.mit.edu; Thu, 7 Sep 89 12:53:46 edt
Date: Thu, 7 Sep 89 12:53:46 edt
From: Jonathan Rees <jar@zurich.ai.mit.edu>
Message-Id: <8909071653.AA04106@zurich.ai.mit.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Baby-Doe and friends
Date: Wed, 6 Sep 89 13:30 PDT
From: Alan Bawden <bawden@parc.xerox.com>
No one has yet suggested the name "RETURN" for the multiple-value creator.
The T 3.0 release notes and implementation suggest it. They just
haven't appeared on this list. Originally T used VALUES, following
Zetalisp, but (if I remember correctly) the implementors were quite
happy to rename it to RETURN and enjoyed (and enjoy) writing code that
was so confusing to Maclisp/Zetalisp programmers. The inverse
procedure is called RECEIVE-VALUES, and there's a macro RECEIVE.
∂08-Sep-89 0426 ramsdell@linus.mitre.org ARGUMENTS/VALUES -> CONSUME/PRODUCE
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Sep 89 04:26:16 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA01456; Fri, 8 Sep 89 07:16:58 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA08260; Fri, 8 Sep 89 07:17:41 EDT
Posted-Date: Fri, 08 Sep 89 07:10:55 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA11926; Fri, 8 Sep 89 07:10:57 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8909081110.AA11926@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: ARGUMENTS/VALUES -> CONSUME/PRODUCE
In-Reply-To: Your message of Wed, 06 Sep 89 11:09:27 -0400.
<8909061509.AA22038@verdi.think.com>
Date: Fri, 08 Sep 89 07:10:55 EDT
I changed my mind and now agree that the name for BABY-DOE need not be
so descriptive as to distinguish between Common Lisp style and Scheme
style multiple values. Having "continuation" in the name for BABY-DOE
is a bit much.
>> From: gls@think.com (Guy Steele)
...
>> Then we can describe the two proposed procedures in a reasonably symmetric
>> fashion: VALUES takes a set of objects headed downward as arguments and
>> bounces them back upward as values. (Think of a mirror. I would have said
>> "reflects" instead of "bounces" except the former already has another
>> technical meaning.) BABY-DOE takes a set of objects headed upward as
>> values and bounces them back downward as arguments.
...
>> Therefore, if we retain the name VALUES for the one, one might reach the
>> logical, if not entirely aesthetic, conclusion that BABY-DOE should be
>> called ARGUMENTS.
>>
>> --Guy
>>
If we do not retain the name for VALUES, one could use Guy's logic to
name the two proposed procedures CONSUME and PRODUCE.
CALL-WITH-VALUES is fine by me but I wish we could find something
shorter. RETURN is my favorite alternative to VALUES. Using Guy's
logic, I guess the symmetric pair of names would then be CALL and
RETURN.
John
∂08-Sep-89 1024 @relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com ARGUMENTS/VALUES -> CONSUME/PRODUCE
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Sep 89 10:24:06 PDT
Received: from MIT.EDU (MIT.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA05259; Fri, 8 Sep 89 12:42:52 EDT
Received: from RELAY.CS.NET by MIT.EDU with SMTP
id AA20452; Fri, 8 Sep 89 12:42:30 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa14090; 8 Sep 89 11:42 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA26946; Fri, 8 Sep 89 09:38:23 PDT
Received: by tekirl.labs.tek.com (5.51/7.1)
id AA00671; Fri, 8 Sep 89 09:42:43 PDT
Received: by tekchips.LABS.TEK.COM (5.51/6.24)
id AA14744; Fri, 8 Sep 89 09:43:24 PDT
Date: Fri, 8 Sep 89 09:43:24 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Message-Id: <8909081643.AA14744@tekchips.LABS.TEK.COM>
To: ramsdell%linus.mitre.org@relay.cs.net
Cc: rrrs-authors%life.ai.mit.edu@relay.cs.net
In-Reply-To: ramsdell@linus.mitre.org's message of Fri, 08 Sep 89 07:10:55 EDT <8909081110.AA11926@huxley.mitre.org>
Subject: ARGUMENTS/VALUES -> CONSUME/PRODUCE
From: ramsdell@linus.mitre.org
CALL-WITH-VALUES is fine by me but I wish we could find something
shorter. RETURN is my favorite alternative to VALUES. Using Guy's
logic, I guess the symmetric pair of names would then be CALL and
RETURN.
Or CONTINUE and RETURN. This has gone on long enough that I have lost
any perspective about what good names would be. Aren't most people
going to CALL-WITH-VALUES via some syntactic extension anyway? If so,
a good but long name is OK.
-Norman
∂08-Sep-89 1318 KMP@stony-brook.scrc.symbolics.com ARGUMENTS/VALUES -> CONSUME/PRODUCE
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Sep 89 13:18:18 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM by life.ai.mit.edu (4.1/AI-4.10) id AA08096; Fri, 8 Sep 89 15:55:01 EDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 654818; 8 Sep 89 15:55:55 EDT
Date: Fri, 8 Sep 89 15:55 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: ARGUMENTS/VALUES -> CONSUME/PRODUCE
To: adams%tekchips.labs.tek.com@relay.cs.net
Cc: ramsdell@linus.mitre.org, Pavel.PA@xerox.com, bawden@parc.xerox.com,
RRRS-Authors@life.ai.mit.edu
In-Reply-To: <8909081643.AA14744@tekchips.LABS.TEK.COM>
Message-Id: <19890908195535.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Fri, 8 Sep 89 09:43:24 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
...
Or CONTINUE and RETURN. This has gone on long enough that I have lost
any perspective about what good names would be. Aren't most people
going to CALL-WITH-VALUES via some syntactic extension anyway? If so,
a good but long name is OK.
Actually, CONTINUE seems to me to be the right name for VALUES, not
for CALL-WITH-VALUES!
Consider the precedent in Fortran: it is a near no-op, whose only
purpose in life is to provide a syntactic way of attaching a label. By
analogy, the purpose of VALUES is only a syntactic device to provide a
way of shoehorning two value producing expressions in a place where only
one would otherwise fit. (Further, consider that in FORTRAN, CONTINUE
takes zero arguments, and then returns to its continuation, which is not
expecting any arguments. So the usages are even compatible. :-)
Getting back to Scheme, though, CONTINUE has the properties I want which
VALUES does not of being agnostic about the number of values. It also
has the property I want that RETURN does not, of not wrongly suggesting
an imperative transfer of control. It suggests that the evaluator will
go about business as usual, but with N values instead of the usual one.
For CALL-WITH-VALUES, I suggest the name should be
(CALL-WITH-CONTINUATION fn continuation)
where the idea would be to think of the second function as effectively
promoted to the status of a continuation. (When that continuation `runs out,'
the current continuation receives its values.)
(CALL-WITH-CONTINUATION (LAMBDA () (CONTINUE 1 2)) CONS)
=> (1 . 2)
I think this has a very nice look to it.
∂08-Sep-89 1329 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu Baby-Doe and friends
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Sep 89 13:29:20 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA08369; Fri, 8 Sep 89 16:18:08 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27757;
8 Sep 89 16:10 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Sep 89 16:11:13 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa27546;
8 Sep 89 15:58 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08173; Fri, 8 Sep 89 15:58:11 EDT
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Fri, 8 Sep 89 15:54:42 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA18546; Fri, 8 Sep 89 12:58:12 PDT
Received: by spencer.cs.uoregon.edu; Fri, 8 Sep 89 12:57:55 PDT
Date: Fri, 8 Sep 89 12:57:55 PDT
From: will@cs.uoregon.edu
Message-Id: <8909081957.AA14302@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Baby-Doe and friends
I like the names RECEIVE-VALUES and VALUES. In response to Norman
Adams's question, I expect to call them directly instead of using
syntactic sugar. That's why I want the thunk to be the first
argument and the receiver the second, and that's why I don't like
the CALL-WITH-XXX names, which (sound like they) imply that the
receiver is the first argument.
We could do worse than ARGUMENTS and VALUES. While reading Guy's
message I though he was going to propose that Baby Doe be called
BOUNCES.
Peace, Will
∂08-Sep-89 1426 gls@think.com ARGUMENTS/VALUES -> CONSUME/PRODUCE
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Sep 89 14:26:15 PDT
Received: from Think.COM (Gateway.Think.COM) by life.ai.mit.edu (4.1/AI-4.10) id AA08522; Fri, 8 Sep 89 16:32:33 EDT
Received: from fafnir.think.com by Think.COM; Fri, 8 Sep 89 16:33:13 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 8 Sep 89 16:30:20 EDT
Received: by verdi.think.com; Fri, 8 Sep 89 16:29:49 EDT
Date: Fri, 8 Sep 89 16:29:49 EDT
From: gls@think.com (Guy Steele)
Message-Id: <8909082029.AA08948@verdi.think.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: adams%tekchips.labs.tek.com@relay.cs.net, ramsdell@linus.mitre.org,
Pavel.PA@xerox.com, bawden@parc.xerox.com,
RRRS-Authors@life.ai.mit.edu
In-Reply-To: Kent M Pitman's message of Fri, 8 Sep 89 15:55 EDT <19890908195535.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: ARGUMENTS/VALUES -> CONSUME/PRODUCE
Date: Fri, 8 Sep 89 15:55 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
...
Actually, CONTINUE seems to me to be the right name for VALUES, not
for CALL-WITH-VALUES!
...
For CALL-WITH-VALUES, I suggest the name should be
(CALL-WITH-CONTINUATION fn continuation)
where the idea would be to think of the second function as effectively
promoted to the status of a continuation. (When that continuation `runs out,'
the current continuation receives its values.)
(CALL-WITH-CONTINUATION (LAMBDA () (CONTINUE 1 2)) CONS)
=> (1 . 2)
I think this has a very nice look to it.
Very nice indeed. A lot worse ideas have appeared (including mine).
Notice that the idiom for returning no values is thus (CONTINUE).
And I can write
(DO ((J 0 (+ J 1)))
((= J 10))
(DISPLAY J)
(DISPLAY (SQRT J))
(CONTINUE))
But I like it anyway.
Note that a "real" continuation can, if desired, be used as the
second argument to CALL-WITH-CONTINUATION, n'est-ce pas?
--Guy
∂08-Sep-89 1542 @relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com name that baby
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Sep 89 15:41:59 PDT
Received: from MIT.EDU (MIT.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA10069; Fri, 8 Sep 89 18:16:05 EDT
Received: from RELAY.CS.NET by MIT.EDU with SMTP
id AA21085; Fri, 8 Sep 89 18:15:42 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa20310; 8 Sep 89 17:13 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA11445; Fri, 8 Sep 89 15:09:17 PDT
Received: by tekirl.labs.tek.com (5.51/7.1)
id AA04223; Fri, 8 Sep 89 15:13:37 PDT
Received: by tekchips.LABS.TEK.COM (5.51/6.24)
id AA16639; Fri, 8 Sep 89 15:14:18 PDT
Date: Fri, 8 Sep 89 15:14:18 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Message-Id: <8909082214.AA16639@tekchips.LABS.TEK.COM>
To: RRRS-Authors%life.ai.mit.edu@relay.cs.net
Cc: adams@tekchips.labs
Subject: name that baby
Perhaps we should just go with the similarity of BABY-DOE and COMPOSE.
A multiple-values cognizant version of COMPOSE might be implemented as
(define (compose g f)
(lambda x (baby-doe (lambda () (apply g x)) f)))
(The argument order is the reverse of traditional COMPOSE.) The
result of COMPOSE is a function that accepts as many arguments as
G. The result of COMPOSE calls F on all the values returned by G.
Given this COMPOSE as primitive, we can define BABY-DOE as
(define (baby-doe thunk bunk)
((compose thunk bunk))
Why not make COMPOSE the primitive and flush BABY-DOE? Even with the
extra parens the name is half the length of "CALL-WITH-VALUE." Or if
those extra parens bother you -- how did you get this far? -- then
(define (compose-and-go a b)
((compose a b)))
Or how about this. If we are going to rename VALUES to CONTINUE, then
rename BABY-DOE to CONTINUE-FROM or CONTINUING. Then KMP's example
reads
(continuing (lambda () (continue 1 2)) cons)
But then why stop at two arguments? COMPOSE is usually n-ary.
(define (swap x y) (values y x))
(continuing (lambda () (continue 1 2)) swap cons)
=> (2 . 1)
-Norman
∂08-Sep-89 1759 KMP@stony-brook.scrc.symbolics.com name that baby
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Sep 89 17:59:30 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM by life.ai.mit.edu (4.1/AI-4.10) id AA11732; Fri, 8 Sep 89 20:44:51 EDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 654998; 8 Sep 89 19:18:47 EDT
Date: Fri, 8 Sep 89 19:18 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: name that baby
To: adams%tekchips.labs.tek.com@relay.cs.net
Cc: RRRS-Authors@life.ai.mit.edu
In-Reply-To: <8909082214.AA16639@tekchips.LABS.TEK.COM>
Message-Id: <19890908231830.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
CONTINUING is an ok substitue for my WITH-CONTINUATION. It seems to address
the criticisms markf had voiced for WITH-CONTINUATION, without sacrificing
any of the good properties I was worried about. I think your example shows
that making it be n-ary would be potentially quite convenient.
[I -especially- like the idea of using a form with a circular
tail to implement iteration. Borrowing on CL syntax:
(CONTINUING (LAMBDA () 1)
. #1=((LAMBDA (I) (PRINT (+ I 1))) . #1#))
:-]
∂11-Sep-89 0516 ramsdell@linus.mitre.org PIPE/CONTINUE
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 11 Sep 89 05:16:04 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA01885; Mon, 11 Sep 89 07:58:08 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA18336; Mon, 11 Sep 89 07:58:56 EDT
Posted-Date: Mon, 11 Sep 89 07:52:09 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA14518; Mon, 11 Sep 89 07:52:10 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8909111152.AA14518@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: PIPE/CONTINUE
In-Reply-To: Your message of Fri, 08 Sep 89 15:14:18 -0700.
<8909082214.AA16639@tekchips.LABS.TEK.COM>
Date: Mon, 11 Sep 89 07:52:09 EDT
Given that I prefer having names for the multiple value procedures
which are descriptive enough so as to distinguish between Common Lisp
style and Scheme style multiple values, you correctly guess I like the
CONTINUING/CONTINUE pair. I especially like CONTINUE for the name of
the multiple value returner.
>> From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
...
>> But then why stop at two arguments? COMPOSE is usually n-ary.
>>
>> (define (swap x y) (values y x))
>>
>> (continuing (lambda () (continue 1 2)) swap cons)
>> => (2 . 1)
We could use Unix terminology and the name PIPE. After all, BABY-DOE
connects two procedures using a "continuation pipeline".
(pipe (lambda () (continue 1 2)) swap cons)
=> (2 . 1)
John
∂11-Sep-89 0940 katz@neon.stanford.edu ARGUMENTS/VALUES -> CONSUME/PRODUCE
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 11 Sep 89 09:40:12 PDT
Received: from Neon.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB04551; Mon, 11 Sep 89 12:08:13 EDT
Received: by Neon.Stanford.EDU (5.61/25-eef) id AA14343; Mon, 11 Sep 89 09:06:42 -0700
Date: Mon, 11 Sep 89 09:06:42 -0700
From: Morris J. Katz <katz@neon.stanford.edu>
Message-Id: <8909111606.AA14343@Neon.Stanford.EDU>
To: KMP@stony-brook.scrc.symbolics.com
Cc: adams%tekchips.labs.tek.com@relay.cs.net, ramsdell@linus.mitre.org,
Pavel.PA@xerox.com, bawden@parc.xerox.com,
RRRS-Authors@life.ai.mit.edu
In-Reply-To: Kent M Pitman's message of Fri, 8 Sep 89 15:55 EDT <19890908195535.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: ARGUMENTS/VALUES -> CONSUME/PRODUCE
I have tried to stay out of the naming battle because in general I
don't care about the names that much. However, I must comment that I
think that there is not enough Hamming distance between
CALL-WITH-CONTINUATION and CALL-WITH-CURRENT-CONTINUATION.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------